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 など) に組み込むようにします。 

これら 2 つのアイデンティティの違いを考慮に入れないセキュリティプログラムは、DevOps チームと IT チームの間に骨の折れる作業や摩擦をもたらす可能性があります。 DevSecOps の約束の実現は、セキュリティを拡張性のある方法でワークフローに確実に組み込むことを意味します。 ここで効果を発揮するのが、クラウドインフラ権限管理 (CIEM) とクラウドネイティブアプリケーション保護プラットフォーム (CNAPP) が統合されたツールです。 これらのツールを統合することにより、クラウドインフラ、Kubernetes、コンテナ、インフラのコード化 (IaC)、アイデンティティ、ワークロードなどを可視化し、制御することができます。

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

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

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

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

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

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

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