多くの企業は、マルチクラウドを意図的な戦略として選んだわけではありません。気づけばそうなっていたというのが実情です。買収した企業がすでに別のプロバイダーで運用していた、あるチームは使い慣れていたからとAmazon Web Services(AWS)を選んだ、別のチームは既存のライセンスに含まれていたためMicrosoft Azureでプロジェクトを立ち上げた、さらに別のチームは開発者がツールを気に入ったためGoogle Cloud Platform(GCP)で静かに環境を構築した、といった具合です。
誰かが全体を設計したわけではありません。そして、各環境のつなぎ目に生じる隙間を管理する担当者もいません。これこそが本当のリスクです。問題は特定のクラウドプロバイダーではなく、複数のクラウドが接する「継ぎ目」にあります。
継ぎ目が問題になる理由
クラウドプロバイダーごとに、IDおよびアクセス管理(IAM)のモデル、デフォルト設定、権限やリソースの構成方法が異なります。AWSで万全に設定したセキュリティポリシーが、Azureでも同じ意味を持つとは限りません。両者が概念的には似て見えても同様です。
プロバイダー間で同等だと思い込み、「あるクラウドで強化したから、すべてで強化できた」とみなしているチームは、気づかないうちに誤っていることが少なくありません。背景にあるモデルが一対一では対応していないからです。
これは仮定の話ではありません。事後に報告される多くのインシデントの背後にある、目立たない現実です。1つの大きな失敗ではなく、2つのシステムの間に生じた、誰も確認する責任を負っていない隙間が原因となっています。
誰も把握していないシャドーリソース
チームごとに異なるクラウドへ独立してインフラを構築すると、資産インベントリはあっという間に実態とずれていきます。数カ月前に終了したプロジェクト向けにあるプロバイダー上で立ち上げたテスト環境は、放っておいても消えません。
そうした環境は、セキュリティチームが実際に監視しているダッシュボードの外に残り続けます。やがて、設定ミスに起因するインシデントで何度も登場する、見落とされたリソースそのものになります。問題は、特定のチームが不注意だったことではありません。すべての環境にどのようなリソースが存在するのか、全体像を把握している人が誰もいなかったことです。
ログの不統一は検知の不統一を招く
マルチクラウドの乱立がもたらすもう1つの被害は、可視性の低下です。プロバイダーによって、デフォルトで記録されるイベント、形式、保存期間が異なります。1つのプロバイダーのログ仕様を前提に検知パイプラインを構築したセキュリティチームは、ほかのプロバイダーに実際の死角を抱えかねません。しかも、調査で必要な データがそもそも存在しない、あるいは誰かが確認しようと考える前に削除されていたと判明するまで、この隙間に気づけないことがよくあります。
StoreBig Data
求められるのは特定プロバイダーの専門知識ではなく、プロバイダーを横断する思考
まさにこの問題に対処するために設けられているのが、1つのプラットフォームのコンソールを使いこなすのではなく、プロバイダーをまたいでクラウドセキュリティを考える力を認定する資格です。International Information System Security Certification Consortium(ISC2)のCertified Cloud Security Professional(CCSP)認定は、クラウドプラットフォーム/インフラのセキュリティやクラウドデータのセキュリティを含む6つのドメインを扱います。「クラウドセキュリティ」は特定ベンダーに紐づく単一のスキルではなく、どのプロバイダーを使う場合にも通用する考え方だという発想に基づいています。
「リスクの大半は、個々のプロバイダーの内部ではなく、クラウド間の継ぎ目に潜んでいます」と、Destination Certificationの共同創業者であるRob Witcher氏は述べています。「AWSの保護に長けたチームと、Azureの保護に長けたチームがそれぞれ存在しても、両者の間に大きな隙間が残ることがあります。2つを合わせて見ることが誰の仕事にもなっていないからです」。CCSPのトレーニングが埋めるために作られているのは、まさにこの隙間です。プロバイダー固有のノウハウではなく、すべてのプロバイダーにまたがるリスクを一度に見通す判断力を養います。
隙間を実際に埋めるには
マルチクラウドをやめる必要も、単一のプロバイダーに集約する必要もありません。組織がマルチクラウドに根付いてしまった以上、集約は現実的でないことがほとんどです。必要なのは、いくつかの意図的な見直しです。1つ目は、3つのダッシュボードを誰も突き合わせないまま運用するのではなく、すべてのプロバイダーの資産と構成を1か所で確認できる統合ビューを用意することです。
2つ目は、各プロバイダーのデフォルト設定を成り行きで引き継ぐのではなく、意図してログの標準を一貫して適用することです。3つ目は、クラウドをまたぐリスクの責任者を明確に置くことです。継ぎ目を見ることを職務とする担当者がいなければ、3つのチームがそれぞれ、自分たちのクラウド間の隙間は他人の問題だと考え続けることになります。
これらの隙間が実際に悪用可能かどうかを、対策が機能していると思い込むのではなく、攻撃者に先に見つけられる前に検証しておくことも重要です。レッドチーム演習が、かつてのように環境ごとに個別にテストするのではなく、クラウド横断のシナリオを取り入れるケースが増えているのもそのためです。
マルチクラウドはなくならない
これらすべてに共通する根本的な目標は、個々の対策というより、単一クラウド構成よりも本質的に分断されやすい環境に真のレジリエンスを組み込むことにあります。マルチクラウドは、大半の企業がいずれ卒業する一過性の段階ではありません。間違いは、複数のクラウドを運用していることではなく、それぞれを個別に守れば全体も守れていると思い込むことです。そうではありません。その間の隙間こそ、次の静かなインシデントが始まる可能性が最も高い場所です。
(画像: PixabayのSuresh Anchan氏による)
翻訳元: https://hackread.com/multi-cloud-blind-spots-security-teams-exposed/
