セキュリティの悲劇は DevOps のるつぼで消える

セキュリティはかつてのものとは違います。あるいは、常にこうだったのかもしれず、若い頃の理想主義が少しずつ薄れたために違って見えるだけなのかもしれません。

セキュリティは二つに分かれています。一方の道では、組織を安全に保つことを目指します。悪意ある行為者を阻止し、データと資産を保護し、脅威から、さらにはユーザー自身の過ちからもユーザーを守ることです。もう一方の道にあるのはコンプライアンスです。組織が規制、契約、その他の基準を満たすようにすることです。いずれの道においてもリスクを管理します。侵害やダウンタイムのリスク、あるいは規制上の制裁金のリスクです。

セキュリティの悲劇は、コモンズの悲劇の反映です。Wikipedia より:

セキュリティコンプライアンスの大半は、セキュリティリスクを低減するために設計されています。少なくとも書面上は。しかし時とともに、次々と登場する基準や規制が、リスクとコンプライアンスを切り離してきました。 コンプライアンス基準はその性質上、組織がセキュリティ対策を自組織のリスクに合わせて調整することを妨げます。これが常に当てはまると申し上げるつもりはありませんが、おおむね当てはまり、特に組織規模が大きくなるほど顕著です。現在広く用いられている MFA やその他の条件付き制限を利用しているユーザーに対して 90 日ごとのパスワード変更を求めることが、セキュリティを向上させるという証拠はありません。パスワードの複雑性要件を考案した人物は、文字どおりそれを後悔しており、効果がないと述べています。また、クラウドプロバイダー上のすべてのストレージボリュームにデフォルト以外の暗号化を求めることには、証拠も健全な科学的根拠もありません。

セキュリティは共有された有限の資源です。使える予算にも、セキュリティ専門家の人数にも、セキュリティ以外の担当者が他の目標を犠牲にしてセキュリティに割ける時間にも限りがあります。コンプライアンスへ引き寄せられるほど、セキュリティに使えるこのプールは少なくなります。コンプライアンスがセキュリティと合致しないほど、セキュリティリスクを低減する取り組みは減っていきます。

これがセキュリティの悲劇です。私たちはリスクをコンプライアンスから切り離し、コンプライアンス違反そのものをリスクにしてしまいました。現実のより大きなリスクがコンプライアンスから切り離されるほど、コンプライアンス体制は硬直化し、防御に充てられるセキュリティリソースは減り、他チームからのセキュリティ活動への支援も乏しくなります。

その好例が、Chris Farris氏との会話で出てきました。要約すると、次のとおりです。

開発者はセキュリティを確かに気にかけています。煩わしいのはコンプライアンスの方です。彼らのアプリケーションを安全にする手助けをすれば、協力してくれます。コンプライアンス担当者が要求するからという理由で、週末に4時間の停止を伴うデータベースの暗号化再構築を命じれば、苛立たせるだけです。

コンプライアンスがすべて愚かなルールだと申し上げているのではありません。しかし、一部のコンプライアンスルールは愚かであり、優れたルールをリスクから切り離して誤って適用することは、まさに愚かです。

DevOps がセキュリティの未来にとってのるつぼとなるのは、クラウドと DevOps の世界では、個々のアプリケーションチームがセキュリティの多くを含めスタック全体に責任を負うようになるからです。新しいサーバー、ネットワーク、ファイアウォールは、git commit といくつかの API 呼び出しだけで用意できます。これは同時に、自分たちのセキュリティとコンプライアンスを管理する負担をそれらのチームに大きく課すことにもなります。中央集権的なセキュリティ組織や共有のセキュリティリソースは依然として存在しますが、最前線においては DevOps チームへの依存が確実に高まっています。クラウドに大きな DMZ を作ることはできません。内部ネットワークと外部ネットワークの境界を、型どおりのゾーンに分類することはもはやできません。クラウドネイティブサービス上に構築された多くのアプリケーションには、そもそもネットワークが存在せず、アプリケーションチームが Infrastructure as Code を通じて展開する JSON で記述された IAM ルールとリソースポリシーに依存しています。

そのため、最近私が手がけたクラウドおよび DevOps 中心のコンプライアンスプロジェクトのかなりの部分は、まず優れたセキュリティを実践し、その上で、実際にはコンプライアンスの文言を満たしていなくても、より安全であるにもかかわらず、満たしているように見える報告書をどう書くかを考えることに費やされています。

考えられる解決策は二つあります。

一つ目は、セキュリティ基準をクラウドと DevOps により適合するよう改訂し、愚かなルールや適用できないルールを減らすことです。こうした取り組みは一部で進んでいますが、これには世代交代が必要であり、待っている時間はないと考えるに至りました。諦めるべきではありませんが、待つ必要もありません。

もう一つは、自動化を活用して、個人にかかるセキュリティとコンプライアンスの負担を可能な限り取り除きつつ、迅速に構築するための自由と裁量を維持することです。セキュリティ全体のプールを縮小せよと申し上げているのではなく、自動化やその他の技術を用いて、価値の低い事柄に時間を費やすという個人への要求を減らすということです。

これは限られたリソースの時間と集中の問題です。そして実際のところ、優れたペネトレーションテストとコンプライアンス監査では、どちらがより価値があるでしょうか。その上で、ペネトレーションテストにいくら費やし、監査にいくら支払っているかをご覧ください。