2021年のクラウドセキュリティに関する推奨事項

2021年のクラウドセキュリティに関する推奨事項（2020年がいつか終わると仮定して）

2020年。あれが起きた年でした。

クラウドセキュリティに関して言えば、2020年はガソリンの炎にロケット燃料を注ぐような1年でした。3年計画が3か月で実行されたのです。そして心地よく燃える炎と同じく、これはメリットや機会をもたらす一方で、いくらかの危険も伴います。個人的には、パンデミックによって出張のほとんどがなくなり、結果としてより多様な顧客層とともに、より多くの仕事を進めることができました。私たちの誰もが、休暇をゆっくり楽しむ機会が得られるふりを始めるこの時期（実際にはそううまくいかないものですが）に、2021年の計画づくりに共通して活かせるトレンドと学びをまとめておくのは良いタイミングだと考えました。

偉大な作家テリー・プラチェットはかつてこう述べました。「人のために火を熾してやれば、その人は1日暖かくいられる。人に火をつければ、その人は一生暖かくいられる」。2021年は、家を焼き尽くすことなく成長を促す燃料として、火を管理することがすべてです。

私がこれまでのプロジェクトで目にしてきた、よくある構造的な失敗の多くに対処しつつ、段階的に取り組むことも十分に可能なクラウドセキュリティの推奨事項をまとめました。2020年にはクラウド導入が大幅に加速し、多くの組織は堅固な基盤を築く時間のないまま速く動くことになりました。それはまったく normal なことですが、体制を固めないまま長く放置するのは望ましくありません。以下の各項目は、極めて公になった失敗事例の根本原因と関連しています。

まずはクラウドガバナンスの是正から

2020年、私は数十の組織と協働し、さらに数百の組織と話をしました。クラウドで一貫して最も多く見られる問題は、ガバナンスの不備です。これにはいくつかのパターンがあります。最も頻繁に目にするのは、組織が開発者に一切の制約を課さないか、逆にセキュリティ部門がクラウドに適さない標準パターンで縛り上げるかという、両極端のケースです。私は両者の中間を取ることをお勧めします。新しいプロバイダーやサービスにはすべてセキュリティ部門の承認を必須とし、セキュリティ部門に「ノー」と言う権限を与える。ただし、その理由を正当に説明できる場合に限ります。そのうえで、耐えがたいほど遅く逆効果なデータセンター向けセキュリティツールをそのまま持ち込むのではなく、クラウドネイティブな実践を反映したクラウドネイティブのポリシーと手順をセキュリティ部門が構築することを義務づけます。そして、Cloud Center of Excellence（クラウド推進センター）という同じテーブルに全員を着かせるのです。世に知られるパブリッククラウドのセキュリティ障害の非常に大きな部分は、技術の失敗ではなくガバナンスの失敗に根があります。

ガバナンスといえば、今こそ「セキュリティチャンピオン」という考え方を採り入れる好機です

セキュリティチャンピオンはBISO（事業情報セキュリティ責任者）ではありません。プロジェクトチームに所属する現場の開発者や管理者で、追加のトレーニングを少し受け、協議会のミーティングでは無料のピザを受け取り（COVIDの隔離が終わるまでは配達で対応できます）、プロジェクトとセキュリティチームの橋渡し役を務める人たちです。窓口であり、擁護者でもあると考えてください。

クラウドセキュリティの可視性を高める

もう一つのよくあるガバナンスの問題は、一部のログを除いてセキュリティ部門をクラウドアカウントから締め出していることです。2021年にはこれを是正し、すべてのクラウド環境（開発／テスト／サンドボックス環境を含む）に対して、セキュリティ部門にツールと読み取り専用アクセスを提供し、さらにインシデント対応用のブレークグラス方式の読み書きアクセスを用意してください。その代わりにセキュリティ部門はポリシーを定め、修復対応のために展開チームに連絡が取れない最悪のケースに限って、自ら緊急変更を実施することとします。可視性には、展開環境の継続的な構成状態（CSPM）と、リアルタイムの変更に関するイベントおよびログのフィード（CDR）の両方を含めるべきです。

攻撃の影響範囲を抑えるために複数アカウントを使っていないなら、今すぐ始める

これは本番用と非本番用を分けるという意味ではなく、アプリケーションスタックごとに複数のアカウントを持つという意味です。なぜでしょうか。アイデンティティが新しい境界であり、少数の大きな環境に詰め込むほど、最小権限の統制を実装するのが難しくなるからです。それも、ほぼ不可能なほど難しくなります。2021年は「新規のものは新規アカウントへ」というルールから始められます。ここでは多くの複雑さ、主にアプリスタック間を相互接続する際のネットワーク面の複雑さを省いて述べていますが、こうした問題はクラウドネイティブのパターンを採用し始めれば解決可能であり、その恩恵は計り知れません。

クラウドネイティブなインシデント対応を強化する

インシデント対応（IR）は2つの点で遅れをとっていると感じます。第一に、クラウドプロバイダーのドキュメントに記載された既定のログ設定は概して理想的ではなく、イベントの発生から通知が届くまでに長い遅延が生じます。これはAWSで最も顕著ですが、どのプロバイダーも同じ課題を抱えています。標準的なSIEM連携に依存していると、攻撃者に大きな時間的猶予を与えてしまうおそれがあります。第二に、対応プロセス自体が適切に定義されておらず、ツールも整っていません。自動化された攻撃に手作業で対応するのは勝ち目のない話です。2021年はIRチームを育成し、イベントベースのアラートを最適化し、インシデントのルーティングと自動化によって対応までの時間差を縮め始めてください。そして、ええ、私は自社製品を勧めていますが、遊びで作ったわけではありません。商用ツールを導入する準備が整っていないのであれば、オープンソースとコーディングで実際に多くのことを自力で実現できます。

IAM/RBACの実装を全面的に見直し、締め直す

不要な権限を削減し、可能な限りリソース制限を追加してください。クラウドプロバイダーが提供するアイデンティティ関連の分析・アラート機能は、ひとつ残らず有効にしてください。属性ベースの制御や条件付きポリシーの利用を始めてください。実際のところ、2020年の主要なパブリッククラウドのセキュリティ障害はいずれもIAMの不備を伴っていました。認証情報の流出、過剰な権限、あるいはIAMの境界を制御するためのMFAや条件付き制限の欠如です。2021年に夜も眠れなくなるテーマが必要なら、まさにこれです。

ガバナンス。基盤となる共有サービス。そしていくつかの戦術的なアップグレード。クラウドコンピューティングが毎年まったく新しいプログラムとツールを必要とするように見えた時期は、すでに過ぎました。2021年は基本を確実に押さえたうえで、拡張性、有効性、コストの面でそれらを改善することが主眼です。私たちは数年前と比べても、どの手法が最も有効かをはるかによく理解しています。重要なのは、近代化の機会を探り、実際にはうまく機能しないレガシーな部分を手放すことです。