ID 管理によるクラウドセキュリティ対策

クラウドのほとんどすべてのものは、過剰な権限や設定ミス 1 つで露呈してしまいます。 適切なクラウド態勢と権限管理があれば、リスクを軽減し有害な組み合わせを排除するのに役立ちます。

クラウドセキュリティソリューションを導入して設定する際には、監視すべき「対象」の量があまりにも膨大であるので圧倒されるのも当然と言えます。監視すべきものには、IaaS やコンテナリソースなどの Kubernetes インフラで実行されるウェブアプリケーション、人やマシンに関連するアイデンティティなどが含まれ、 クラウドセキュリティ部門は、各リソースのサービスアイデンティティを管理するほか、スキャンして脆弱性や設定ミスがないかを確認する必要があります。 監視すべきものがあまりにも多いので、こういった脅威要因に対抗するために、多くの組織は個別のツールやポイントソリューションを利用しようとします。 しかし、そうすると、組織環境内でさまざまなセキュリティ略語があふれる事態となり、結果的に、これらのばらばらな製品をすべて設定して導入するには非常に大きなコストがかかります。 

多くの場合、各ツールは独自のセキュリティ調査結果を大量に生成し、個別の重大度のメトリクスを基にして機能します。 そのため、技術的に高度なツールを使用しても、セキュリティ業務はスプレッドシート地獄に後戻りして、すべての検出結果の突き合わせや優先順位付けをしなければならない状態になります。

クラウドでのアイデンティティ保護の重要性

より効果的なセキュリティ戦略を導入するためには、攻撃者がクラウドインフラを侵害する際に何を達成しようとしているかを特定することから始める必要があります。 最近では、ほぼすべてのクラウド侵害で、アイデンティティや権限の設定ミスが悪用されていることが明らかになっています。 Identity Defined Security Alliance (IDSA) の調査「2022 Trends in Securing Digital Identities (デジタルアイデンティティの保護における 2022 年の動向)」によると、84% の企業が、調査対象の 12 か月間にアイデンティティ関連の侵害を受けたことが明らかです。その理由は、単にアイデンティティがクラウドで実行と構築が行われるあらゆるものに密接に結び付いているからだけでなく、解決が極めて複雑な問題であることに起因しています。 アイデンティティ管理に関係するリスクを正確に理解しようとすると、非常に多くの要因がからんでいることがわかります。

使用中のパブリックの Amazon EC2 インスタンスに既知の悪用可能な脆弱性が含まれていてもいなくとも、手動またはコードで設定されているインフラに設定ミスがあってもなくても、まったく関係なく、クラウドのエクスポージャーを侵害する攻撃者は直ちにアイデンティティを狙います。 攻撃者は、機密データなどのリソースへのアクセスを企ててラテラルムーブメントや権限昇格を図るために権限をテストします。 アイデンティティはクラウドの境界線であり、広範囲に影響があるため、アイデンティティと権限のセキュリティを、総合的なクラウドセキュリティプログラムの基盤とすべきです。 

サービスのアイデンティティと人のアイデンティティの違いを理解する

アイデンティティを保護する際には、最小権限の原則を実現するために、サービスのアイデンティティと人のアイデンティティの違いのほかに、保護するアプローチの違いも理解することが重要です。 サービスのアイデンティティは、ワークロードへサービスを提供するように、そして首尾一貫した予測可能な根拠に基づいて機能するように作られています。 割り当てられている権限と、実際に使用されている権限を比較して評価することは、「有効な権限」を理解するために重要です。 サービスのアイデンティティは特定の目的のために組み込まれており、その要件は滅多に変わらないため、アイデンティティの権限の規模を活動に応じて必要最小限まで適正化することができます。これが最小権限の原則です。 

これとは対照的に、人のアイデンティティは人間が実際に使用するために作られているので、予測がつきません。特に臨時業務が発生したときに、特定の人や活動に対する権限を適切なレベルに設定することが困難になります。 ゼロトラストを実行するには、統合されたジャストインタイム (JIT) アクセスプログラムの導入が鍵になります。 人間のユーザーがクラウドに全くアクセスできないようにすることはどのような組織であっても不可能であり、 非現実的です。 しかし、そのリスクを大幅に削減することは可能で、その方法は次のようなものです。 まず、DevOps チームが重要な環境での特定の業務のために、クラウドへの短期間のアクセスをプログラムでリクエストできるようにします。くわえて、この短期間のアクセスのワークフローを既存のコミュニケーションツール (Slack、Microsoft Teams など) に組み込むようにします。 

人とサービスのアイデンティティの違いを考慮に入れないセキュリティプログラムは、DevOps チームと IT チームの間に困難で仕事のしにくい状態をもたらす可能性があります。 DevSecOps の主旨を実現するには、セキュリティを拡張性のある方法でワークフローに確実に組み込まなければなりません。 ここで効果を発揮するのが、クラウドインフラ権限管理 (CIEM) とクラウドネイティブアプリケーション保護プラットフォーム (CNAPP) が統合されたツールです。 これらのツールの統合が、クラウドインフラ、Kubernetes、コンテナ、インフラのコード化 (IaC)、アイデンティティ、ワークロードなどの可視化と制御を可能にします。

CNAPP と CIEM が統合されたセキュリティソリューションでは、以下のことに注意してください。

• 権限のインサイトと可視化: セキュリティの古い格言にもあるように、見えないものは守ることができません。 リソースと権限とそれらの挙動をマルチクラウドで正確に可視化することが、最も重要な出発点になります。 
• 継続的なリスク評価: ネットワークのエクスポージャー、設定ミス、危険な権限、露出した機密情報、アイデンティティに関連する脅威 (異常なデータアクセスなど) といったリスク要因を検出して評価するために、クラウド環境を継続的に監視する必要があります。
• 最小権限の原則の適用: 統合されたツールは、最小権限のポリシーによって自動的に権限を正常に維持するガードレールを設定できることが必要です。
• 修正の合理化: リスクの所在がわかれば、問題はツール内で簡単に修正できるはずです。その場合、セキュリティ戦略に沿って活用できる範囲で修正を自動化することもできるでしょう。 
• 開発者中心のアクセス制御: DevOps チームにはワークフローにセキュリティを統合できるツールを提供すれば、セキュリティが制御できないという不満も解消されます。 

文脈でアラート疲れに対抗する

多くのセキュリティチームは、頻繁に発生するアラートに対応するためにコントロールやポリシーの調整に時間を割いていますが、それより優れた方法は、CNAPP や CIEM などのセキュリティツールを、アタックサーフェス全体の豊富な文脈を提供する単一のプラットフォームへ統合することです。 統合されたセキュリティツールを使用して、「重大」の正確な意味を標準化することや、攻撃者がクラウド環境に損害を与えるために悪用する可能性がある攻撃経路をもっとよく理解することができます。 くわえて、新たな脅威やゼロデイ脆弱性が発見されたときに更新するのが非常に簡単になります。 

たとえば、外部からアクセス可能な実行中ワークロードがクラウド環境内に 100 個あるが、重大な脆弱性があるのはそのうち 10 個のみ、重大な脆弱性に加えて高い権限があるのはさらにその中の 5 個のみであるとします。 セキュリティチームはこのような文脈を用いて、悪用される可能性が最も高いものに基づいて、チームがどこに力を入れるべきかについてインサイトを得ることができます。 ポイントソリューションには脅威への効率的な対処に必要な統合が欠如しており、アイデンティティを重視した文脈もないため、往々にしてセキュリティチームは、公開されている 100 個のワークロードすべてに対処しようとする事態に陥ります。 

リスクとエクスポージャーを把握できる統合された機能が重要なのです。 統合された機能は、インフラや脆弱性の観点からだけでなく、総合的に評価して、環境内で実際に起きていることに基づいてリスクスコアリングを動的に調整する方法としても正解と言えます。

クラウドのアイデンティティ保護に関する詳細については、こちらのオンデマンドウェビナー「Managing Security Posture and Entitlements in the Cloud (クラウドでのセキュリティ態勢と権限の管理)」をご覧ください。