2021年のDevopsとDevsecopsの普及を左右する9つのトレンド

原文(投稿日：2021/04/15)へのリンク

過去数年間にわたって、DevOpsとDevSecOpsは、多くの企業のソフトウェア開発や管理に対するアプローチを革新してきました。これらの用語は頻繁に使用されるようになり、事実上、綿密な計画の下で実践されるソフトウェア開発の代名詞になっています。

DevOpsとDevSecOpsの価値を理解することは重要ですが、しかしこれらは、あらゆる規模に適合するような、堅牢かつ不変のパラダイムという訳ではありません。それどころか、どちらのアプローチも、それ自体がいまだ発展途上なのです。来年のDevSecOpsは、もしかすると今年のDevSecOpsとはまったく違っているかも知れません。

今回の記事では、その現在進行中の発展について見ていきます — DevOpsとDevSecOpsの採用を推進し、影響を与える9つの重要なトレンドを探し出し、そのそれぞれについて、開発や管理に関わる数多くのアプローチとともに説明します。

1. DevOpsの興隆

まず最初に、DevOpsとDevSecOpsという、現時点で最大のトレンドについて話さないわけにはいきません — どちらのアプローチも、この数年間で人気が爆発的に高まっているという事実があります。 

2つのアプローチがなぜ、これほどの人気を得ることになったのか、ほとんどの開発者やマネージャにはよく分かっています — サイバーセキュリティのリスクを管理するための、より統合的な手段を提供するのはもちろんですが、同時に(直感的でない部分もありますが)開発プロセスやチームを極めてアジャイルな存在にしてくれる、という理由があるのです。 

これはDevOpsが、運用チームと開発チームに対して、必要なタスクを効果的に拡散してくれるからです。作業をする人数が少ないほど、チームはより効率的になるのです。 

これらのアプローチを採用するには課題もありますが、それによって得られる潜在的メリットは、一般論として、このリスクを正当化するには十分なものです。大部分の開発チームにとって、これはまず、DevOpsプロセスに移行することを意味しています。その後、DevOpsが発展してDevSecOpsになるのです。

この移行中に得られる運用面でのメリットの他にも、たくさんのメリットがあります。見落とされがちなメリットのひとつが、DevOpsが広く普及したことにより、多くの開発者にとってDevOpsが既定の作業方法になっていることです。オープンソースのコントリビュータでDevOpsのエキスパートである、Cloud DefenseのBarbara Ericson氏によれば、"DevOpsはソフトウェアエンジニアリング界で突如として一般的なものになったため、この用語が2009年までは存在さえしなかった、という事実はほとんど認識されていません ... DevOpsは、それを実現するためのツールやベストプラクティスを超えて広がっているのです。DevOpsの導入を成功させるには、文化や考え方を変える必要があります。"

この傾向は今後も続いていく可能性が高いので、DevOpsへの移行に後れを取っている企業は、将来的に才能のある開発者を採用することが難しくなるかも知れません。

2. モノリスからマイクロサーバへ

それでは、DevOps採用を後押しし、今後もその将来を定義し続けるであろう、技術的トレンドに話題を変えましょう。最も広い技術的レベルにおいては、DevOpsへの移行は、モノリシックなアーキテクチャからの離別と、より小さく、よりアジャイルなコンポーネントのネットワークによって構成されるアーキテクチャへの移行が同時並列的に成し遂げられたものです。

この一般的な傾向は、いくつかの形で現実となって現れています。コンテナ化に対する人気の上昇 — この後すぐ取り上げます — によって、ソフトウェアのデプロイメントは、コンテナ階層を通じて処理されるのがごく普通になりました。もっと広いレベルでは、これらの新しいアーキテクチャは、いずれも一元管理されたサーバやシステムからマイクロサービス — 独立的にデプロイ可能なサービスのスイートとしてソフトウェアアプリケーションを設計する手法へという、広範な移行の兆候なのです。

この傾向に批判がないわけではありません。企業にとっては、機会と同じ位の数の課題がもたらされることも少なくないのですが、マルチクラウドセキュリティ管理のための堅牢で成熟したアプローチが開発され続けることで、全体的なこの方向性は、もはや後戻りできないものになっています。

3. 既定としてのクラウド

マイクロサービスとコンテナ化に向けた動きは、関連するトレンドを加速する上でも有効です。そのひとつが、すでに10年近く実施されている、既定のアプローチとしてのクラウドにおけるソフトウェア管理です。事実、多くの若い開発者にとっては、もはやこれが"トレンド"であること自体が不自然かも知れません。データ保護が特に重要な要件である場合を除けば、私たちは常に、データの透明性を追求していたのではなかったでしょうか？

そうなのです。DevOpsが最初にコーディングと管理のパラダイムとして確立された頃を振り返ると、移行を計画する上での大きな悩みのひとつは、さまざまなニーズ — 開発者、運用担当者、スタッフ、カスタマサービス部門など — を抱えたチームが、効率的かつ安全にアクセスできるクラウドサービスを構築することでした。現在ではこのニーズに合った、よく設計されたサービスがたくさん存在するので、クラウド上での実行を前提としたソフトウェアを立案できるようになりました。しかしながらこれは、DevOpsモデルが出現した時点で前提条件として持っていたものではなく、成功を積み重ねていった結果なのです。

4. Kubernetes

もう少し具体的な話をしましょう。DevOpsとDevSecOpsの発展におけるコンテナ化の影響については、誇張し過ぎるということはありません。そして、大部分の企業にとって、コンテナ化の意味するものはただひとつ — Kubernetesなのです。 

Kubernetesの普及は、コンテナ化インフラストラクチャの一部としてのDockerとともに、これまで述べた移行のいくつかの部分に直接的な関わりを持っています。事実としてコンテナ化は、現在のソフトウェア開発に使用されている分散型超並列アプローチにおいて、必要不可欠な存在になっています。コンテナ化のないDevOpsは、もはや想像すらできません。

これはKubernetesが、中央のコントロール配下ではない、注意深く選択された創造的混乱(creative anarchy)をベースとしたインフラストラクチャの構築を促進してくれるからです。現在は、大半のDevOpsチームが、経験の浅いメンバに対しても、アクティブなソフトウェアリポジトリに比較的大きな変更を加えることを許可していますが、これはコンテナ化による継続的な検出機構が、このような変更を裏で支えてくれているからです。これによって、アップデートやアップグレードの管理が大幅に高速化されているのです。

実際に、Kubernetesとコンテナ管理システムを最大限に活用すれば、運用チームによるソフトウェアによる更新管理作業の必要性は低くなります。プラットフォームがシステムのスタックを運用して、個々のチームが、それぞれ適切と思われるタイミングで変更をリリースできるような権限とアイソレーションを持てばよいのです。これは一般的に'NoOps'と呼ばれるシナリオで、オートメーションが高度化してデプロイが容易になるにつれて、今後普及していくものと思われます。 

5. アジャイルインフラストラクチャ

柔軟性を指向するこれらの動きは、ソフトウエア開発ライフサイクルの一部として最も身近なものですが、そのルーツが他の分野にあるということも覚えておく価値があると思います。運用プロセスにおけるリアルタイムな柔軟性への要求は、事実として、過去何十年にもわたって発展を続けてきた製造業での設計における同様のトレンドに、その起源をたどることができます。

製造業の世界では、フレキシブルなインフラストラクチャ設計には長い間、"アジャイル"アプローチという名称がありました。このアプローチでは、高度に堅牢で、高度に接続され、それでいて比較的安価なインフラストラクチャの重要性が強調されていました。また、大手の製造企業に対して、コラボレーション、組織化、レジリエンスを達成するためのスキルセットの多様化、短期のイテレーション、自己改善型の作業プロセスといった、ソフトウェア企業の持つ数多くの特性を教えたのもこのアプローチでした。

その影響力は今、逆の方向に変わったように思えます。ソフトウェア開発者は現在、製造業の設計者たちがIoTネットワークに関する豊富な経験を持ち、特にこれらのシステムをアジャイルかつ安全に保つことのできるハードウェアインフラストラクチャ設計のためのアプローチを実践していることを認めているのです。 

6. エンドユーザ・オートメーション

DevOpsがもたらすものは、しかしながら、開発者や運用スタッフの作業を簡単にすることだけではありません。両方のチームをひとつのユニットにまとめることによって、相互のコミュニケーションが大幅に効率的になり、両チームがこれまで関与してきたプロセスがより効果的になる、ということも期待されるメリットのひとつです。

大部分の企業において、この2つのチームからのインプットを必要とする最も重要な協調的プロセスは、ソフトウェアのリリースでしょう。過去数年間、新しいソフトウェアのリリースやデプロイメントの簡略化を目的とした、オートメーションツールの新たなファミリが現れているのは、この理由からなのです。参照コード検索ツールという、コードデリバリに関わる一般的な手作業を自動化するツールなどは、この一例と言っていいでしょう。ここで得られるのは、新たなソフトウェアをリリースする(あるいは既存のソフトウェアをアップデートする)技術的プロセスの完全な自動化です。

当然ですがこれは、開発チームや運用チームがソフトウェアのリリースに関与しなくなる、という意味ではありません。これらのチームが、ソフトウェアをリリースする方法の技術的な詳細よりも重要なこと — ソフトウェアがユーザニーズや管理上の要件に適合していることの確認 — に集中できるようになる、という意味なのです。

7. 保護ではなく回復力を

DevOpsやDevSecOpsはおもに管理上のソリューションとして開発されたものですが、ソフトウェア会社がサイバーセキュリティにアプローチする方法に対しても影響力を持っています。

すでに指摘したように、DevOps時代におけるインシデント管理は、かつて行われていた危機管理の類とは大きく異なっています。ソフトウェアパッケージの新バージョンの出荷(文字通り船で出荷(shipping)される場合もありました！)が年1回であった時代には、リリース毎にセキュリティ上の脆弱性を厳密にテストする時間がありましたし、見落としていた部分を数か月費やして修正するようなことも珍しくはありませんでした。

それが悪いとは言いませんが、今はそんな時代ではありません。DevOps時代がもたらした短期間のリリーススケジュールによって、多くのセキュリティアナリストが、自身の仕事はソフトウェアを保護することではなく、ソフトウェアに回復力(レジリエンス)を提供することである、と考えるようになりました。すべてのセキュリティ上の脆弱性が修正可能であるという非現実的な期待をするのではなく、DevSecOpsチームの多くは今、ソフトウェアはすべての部分が脆弱であるという前提に立って、その結果から他の部分を保護することに注目しているのです。

8. 高度なマルウェアとAPT

分散型クラウド、マイクロサービス、クラウドファーストなソフトウェア開発への移行は、最高のDevOpsチームというものを、ソフトウェア開発や管理に対する従来型のアプローチよりも、はるかにフレキシブルな存在にしました。しかしながら、そこには大きな課題もあります。

その最も直接的なものは、高度な形式のマルウェアの台頭です。これらは、現代的なソフトウェア開発アーキテクチャの持つ分散性を利用して、APTによって展開されることが少なくありません。Privacy Canadaのサイバーセキュリティの専門家であるLudovic Rembert氏によると、マルウェアは今日のソフトウェアにおいても依然として大きなリスクなのです。"無害に見えるソフトウェアパッケージに、悪意を持ったソフトウェアが組み込まれている場合もあります。こういったプログラムは、インターネットからダウンロードされることが多く、サードパーティ製のソフトウェアに含まれている場合もあります ... これらのWebサイトは、悪意を持った者に攻撃された正当なWebサイトである場合もありますし、悪意を持ったソフトウェアに感染させる目的のみで作成されたWebサイトの場合もあります。"

さらに高度なマルウェアの中には、分散型クラウドシステムのさまざまなコンポーネント間で渡されるデータを傍受することで、そのセキュリティを損なうものも存在します。

これは当然、長くDevOpsアプローチで開発を続けてきたチームが今になってDevSecOpsに移行し、多くの企業が"ウォーターフォール"アプローチから直接DevSecOpsへの移行を合理的と考える理由のひとつになっています — 移行を慎重に計画して、セキュリティチームを開発プロセスやメンテナンスプロセスに関与させることで、ソフトウェアの安全性は大きく向上します。ただしこれは、後付けて追加するのではなく、インフラストラクチャ設計時に重要な部分として捉えておくことによって、初めて実現可能なものです。

9. AIとML

最後に忘れてならないのは、AIツールとMLツールです。DevSecOpsチームがこれらの技術を大々的に展開する方法はいまだ模索中ですが、AIが将来のDevOpsに大きな影響を与えることはほぼ間違いないでしょう。

ただし、どのようなものになるのかは、いまだ不明な部分があります。もしかすると、AIツールやMLツールの提供可能な高度なオートメーションによって、多くのチームがDevOpsのOps部分を完全に忘れ去ることができるかも知れません。この想像上のユートピアでは、運用はすべてAIによって処理されます。開発者は現実のコード実装に関する複雑さに対処することなく、コードを自由にリリースすることが可能になります。

夢物語に聞こえるとすれば、おそらく、そのとおりだからです。AIツールやMLツールは、繰り返しの必要な"下働き(leg work)"作業をソフトウェア管理から取り除くのは可能ですが、完全に排除することはできません。それよりも、運用担当チームが自動化された管理システムのマネージャになる、という方が現実的でしょう。

将来像

ここまでで、DevSecOpsの導入を推し進める重要なトレンドが分かりました。 

あるいは、DevSecOpsのさまざまな形式、と言うべきかも知れません。なぜならば、DevOpsの次は何かを考える時、私たちはすぐさま問題に突き当たるからです — DevOpsを採用している数と同じくらい多くのプラクティスが存在して、それぞれが自身のロジックに基づいて発展しているのです。

そうではあっても、ソフトウェア開発が将来的にどの方向に進むのかを把握することはほぼ可能であって、ここまで説明した方法がそれです。それは、よりアジャイルな、より分散的な、より自動化されたものになるでしょう。最終的には、開発チームと運用チームの双方にとって、素晴らしいニュースです。 

著者について

Sam Bocetta氏は元セキュリティアナリストで、海軍のネットワークエンジニアとして長く勤務していました。現在はセミリタイアして、セキュリティやプライバシ技術に関する教育に広く携わっています。氏の仕事の多くは弾道システムの侵入テストに関するもので、ネットワークを分析してエントリポイントを探し、その結果に基づいてセキュリティ上の脆弱性評価を作成していました。さらに氏は、高度な"倫理的"ハッキング演習の計画、管理、実施を通じて、海軍(陸上と海上の両方)で使用されているエンタープライズシステムにおける、脆弱性の特定やリスク状況の軽減を支援していました。アプリケーションやネットワークに対する脅威の特定と阻止、攻撃ベクトル領域の低減、脆弱性の除去、一般的な報告作業が業務の中心でした。氏はネットワークの弱点を特定し、さまざまなサイバー脅威に対してネットワークを強化するための新たな戦略を立案することができます。アーキテクトや開発者と緊密なパートナシップを築くことによって、氏は、アプリケーションにおいて特定された脆弱性を緩和するコントロール方法を特定し、さまざまな脅威の戦術、技法、手順の模倣によりセキュリティ評価を実施してきました。