CSPM – 最小権限の原則を実践

By 清水 孝郎 - NOVEMBER 23, 2022

SHARE:

本文の内容は、2022年11月22日にNIGEL DOUGLASが投稿したブログ(https://sysdig.com/blog/cspm-least-privilege-principle/)を元に日本語に翻訳・再構成した内容となっております。 クラウドセキュリティポスチャーマネジメント(CSPM)は、クラウドインフラクチャー全体のリスクの特定と是正を自動化することを目的としています。CSPMのフレームワークの中核となる要件は、最小権限の原則を強制することです。

クラウドインフラストラクチャーエンタイトルメントマネジメント(CIEM)ソリューションと重なる部分があります。CIEMは、CSPMの後に登場した新しい分類です。CIEMは、従来のCSPMツールで想定されるセキュリティ・ギャップを解決するためにビルドされたもので、誤設定にのみ焦点を当てたものです。CIEMツールは、パブリッククラウドのデプロイで一般的になっている、アイデンティティと権限に対する不十分なコントロールに対処するものです。
従来のオンプレミス環境とは異なり、クラウドではインフラストラクチャーとアプリケーションのプロビジョニングがはるかに迅速に行われる傾向があります。このため、クラウドユーザーは仮想マシンやインフラストラクチャーの立ち上げや撤収に、より余裕を持って対応できるようになります。コンピュート(計算機)の調達に頭を悩ませることも、ほとんどなくなります。テスト用に短期間のテンポラリープロジェクトを作成し、CLIコマンド1つでそれらを削除することができます。これらのテスト構成にはすべて、特定の権限を持つクラウド ID が関連付けられています。つまり、クラウド・プロバイダーはクラウド・プラットフォーム自体のセキュリティを全力で強化しますが、そのプラットフォームを利用する企業は、自社のアプリとインフラストラクチャーに対して独自のセキュリティ要件を実装しなければなりません。
このブログでは、CSPMについて説明し、最小権限の原則を導入することによって、これらのさまざまなプラットフォームの設計を比較することにします。

最小権限の原則とは?

CISA (Cybersecurity & Infrastructure Security Agency) によると、最小権限の原則とは、対象者がタスクを完了するために必要な権限のみを与えるべきだというものです。アクセス権を必要としない対象には、ゼロトラストアーキテクチャー設計の一環として、アクセス権を与えるべきではありません。
Least Privilege Practice in CSPM
弱い、あるいは不適切に適用されたアイデンティティ・ポリシーとその特定の権限は、クラウドにおける攻撃者の脆弱なターゲットとなります。パーミッションの変更、ビルドテンプレートの設定ミスを継続的にスキャンし、最終的に元の安全なテンプレートからのドリフトを防ぐことで、将来的な侵害を恐れることなく、自信を持ってコードのデプロイを自動化することができるようになるのです。
また、アイデンティティは、単にユーザーアカウントを意味するものではないことを認識することも重要です。自動化とコンテナ化により、マシンのアイデンティティも同様に、いやそれ以上に重要です。

アクティビティログに基づくクラウド監査と脅威の検出

脅威の検知を行うためには、まず、クラウドを可視化する方法が必要です。
オープンソースのランタイムセキュリティ脅威検知・対応エンジンであるFalcoを利用すれば、クラウド環境上で動作するアプリケーションやコンテナの挙動を観察することで、ランタイムに脅威を検知することが可能です。Falcoは、Falco Pluginsを介して、複数のクラウド環境にまたがる脅威検知のサポートを拡張しています。クラウド環境にFalcoエージェントをインストールするのではなく、クラウド事業者からFalcoにログをストリーミングすることで、ポスチャー管理の実行に必要な深い可視性を確保しています。
例えば、Falco CloudTrailプラグインは、AWS CloudTrailのログを読み、CloudTrailのログエントリごとにイベントを発することができます。このプラグインには、CloudTrailのログに含まれる以下のような興味深い/疑わしい/注目すべきイベントを特定するために使用できるアウトオブボックスのルールも含まれています。
  • 多要素認証を使用しないコンソールログイン
  • ユーザーに対する多要素認証の無効化
  • S3バケットに対する暗号化の無効化
Falcoはオープンソースであるため、Hashicorpとのコミュニティセッションで説明されているように、ユーザーは独自のFalcoプラグインをビルドすることができます。ユーザーはFalcoプラグインをビルドすることで、Falcoのルールライブラリで既に提供されていない追加の洞察を得ることができ、最小権限の誤実装があったかどうかをよりよく理解することができます。これらの深い洞察により、ユーザーは理論上、最小権限原則の実装を改善することができます。Do It Yourselfの構成がすべての組織でうまくいくわけではないことを明記しておくことは重要です。そのため、Sysdig SecureはオープンソースのFalcoのルールエンジンをベースにして、ポリシーの適用を簡素化し、管理するアプローチを提供しています。

クラウドにおけるMFA エンフォースメント

クラウドのセキュリティについて言及されるとき、最初に思い浮かぶのはMFAによるセキュアなアクセスでしょう。MFAは、(管理者だけでなく)すべてのユーザーにとって必須のものです。
MFA を使用しない認証を検出することは、CSPM ソリューションで最小権限を適用するために必要な要素です。すべてのクラウドプロバイダーにとって一般的なベストプラクティスとして、すべてのユーザーに対してMFAを有効化する必要があります。
インシデントが発生したときに警告してくれるFalcoのようなツールは、組織のリスクを減らすのに役立ちます。
Falcoでは、MFAを使用しないAWSへの対話型ログインを検出するために、シンプルなYAMLマニフェストを設定することができます。
最後に、攻撃者が初期アクセスを得ようとするもう一つの例として、MFA FatigueやSpammingがありますが、これが発生したときに検知して警告することも可能です。
AWSAzureGoogle Cloudの対応リストMFAツールの詳細については、ハイパーリンクを用意しています。

クラウドホストスキャン

多くの場合、CSPMプロバイダーはエージェントを避け、可能な限りAPIを使用するため、これを “エージェントレス” スキャンと呼ぶ人々もいます。従来のEDRベンダーがワークステーションにエージェントを手動でインストールしたり、グループ・ポリシー・オブジェクト(GPO)を介してプッシュ型デプロイを行うようなことは、もはやありえません。
クラウドホスティングされたVM/EC2インスタンスは定期的にスピンアップされ、削除されるため、クラウドテントから直接ランタイムでログを計算する方が良いアプローチと言えます。Falcoは、各クラウドプロバイダーの監査ログサービスに簡単にプラグインし、ほぼリアルタイムの検知を強化し、お客様のクラウド環境のセキュリティを向上させます。
監査ログは、オンプレミス環境で期待されるのと同じレベルの透明性をもって、お客様のクラウドリソース内で「誰が、どこで、いつ、何をしたのか」に答えることを支援します。監査ログを有効にすることで、セキュリティ、監査、およびコンプライアンスの担当者は、クラウドのデータとシステムの脆弱性や外部データの不正使用の可能性を監視することができます。
クラウド監査サービスの例としては、AWS CloudTrail、GCP AuditTrail、Azure PlatformLogsなどがあります。
一度接続すれば、誰がインフラストラクチャーに変更を加えたか、その変更を行ったユーザーにどのような権限が与えられているかを詳細に把握することができるはずです。一般的なクラウドプロバイダーの監査ログに接続することで、関連するすべてのユーザーの変更を追跡することができるはずです。クラウド上の不正なホスト接続を阻止するための防御策については、今後説明する予定です。それまでの間、Falcoを検知ツールとして使用し、特定することが重要です。
- rule: Outbound or Inbound Traffic not to Authorized Host Process and Port
  desc: Detect traffic that is not to an authorized VM process and port.
  condition: >
    allowed_port and inbound_outbound and container and
    container.image.repository in (allowed_image)
  output: >
    Network connection outside authorized port and binary
    (proc.cmdline=%proc.cmdline connection=%fd.name user.name=%user.name
    user.loginuid=%user.loginuid container.id=%container.id evt.type=%evt.type
    evt.res=%evt.res proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid
    proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath
    user.uid=%user.uid user.loginname=%user.loginname group.gid=%group.gid
    group.name=%group.name container.name=%container.name
    image=%container.image.repository)
  priority: warning
  source: syscall
  append: false
  Exceptions:
  - name: proc_names
    comps: in
    fields: proc.name
    Values:
    - authorized_server_binaries

このブログ記事では、Anchore や Open Policy Agent (OPA) などの CNCF が認めたオープンソースツールを使用することで、クラウドホストやワークロードに最小権限を強制することもできることを説明します。

クラウドエンタイトルメント

企業には、関連するすべてのクラウド活動を集約し、ユーザーごとにフィルタリングできる「アイデンティティ&アクセス」(IAM)ビューが必要です。クラウドユーザーに与えた特定の権限が利用されていない場合、そのユーザーから権限を削除することを検討する必要があります。同様に、ユーザーが活動していない場合、またはユーザーに関連付けられたロールが使用されていない場合、最小権限の原則の一部として、これらのロールの削除を検討する必要があります。
このように、ユーザーのライフサイクルを安全に保ち、日々の業務に影響を与えることなく監査を行うことができるようになるのです。

ユーザー権限の制限

エンドユーザーの要件と行動に基づいて、ユーザー固有のポリシーを作成することを強くお勧めします。特定のアイデンティティに与えられる権限を制限することで、そのユーザーアカウントが潜在的に侵害される場合の影響範囲を制限することができます。
このケースのユーザーがクラウドテナントを使用してマネージドKubernetesクラスターをスピンアップするだけなら、例えばLambdaのようなServerless機能に変更を加える必要はほとんどないでしょう。その結果、現在使われていない添付のポリシーから、与えられた3つの AWSLamdaBasicExecutionRole 権限を削除する必要があります。
Falcoのようなツールは、潜在的な侵害に関連するパターンや行動を検出するのに理想的ですが、ツールやアプリケーションにわたる人間以外のアクセスを安全に認証、承認、監査するためには、IAMソリューションが必要です。例えば、CyberArk ConjurはCNCFのプロジェクトで、インストールされているオープンソースツール、実行されているコンテナ型アプリケーション、さらに堅牢なシークレットマネジメントの提供によるクラウド環境など、クラウドスタック全体でIAMコントロールを行うオープンソースインターフェイスを提供しています。
Kubernetesとクラウドでは、シークレットとは、アカウント情報、APIキー、アクセストークンなどの機密情報を保持するために特別に作成されたオブジェクトです。もしシークレットが流出したり、クラウド環境以外の人がアクセスした場合、共有されたクレデンシャルを介して他のサービスにアクセスされる可能性があります。
Conjurでは、rilesによってこれに対処することができます。ルート管理者ロールは、Active DirectoriesのGPOツリー構造に緩く似た次のような特徴を持ちます。
  • ルートポリシーの所有者です。したがって、そのメンバーは、rootの下でポリシーをロードすることができます。
  • ルートから分岐したポリシーの明示的な所有者ロールが指定されていない限り、すべてのポリシーを所有します。
次のステートメントは、ルート管理者グループのロールを作成します。Sysdig-root-admins は、これらのグループに対する権限をユーザーに与え、非ルートのポリシーリソースの読み取り権限のみをユーザーに与えます。
# add the following to your root policy file
# declare two users and a group
- !user nigel
- !user pietro
- !group sysdig-root-admins
# add members to the group
- !grant
  role: !group sysdig-root-admins
  Members:
    - !user nigel
    - !user pietro
# give the group privileges on some resources
- !permit
  role: !group sysdig-root-admins
  Privileges:
    - read
  Resources:
    - !policy root

もし、ユーザーアカウントからこれらのパーミッションを削除するとしたら、ユーザーアカウントの乗っ取りに関連する可能性のある影響範囲を制限することになり、最終的にセキュリティ姿勢を向上させることができます。
ユーザー「nigel」がアカウントを乗っ取られたと仮定すると、彼らは自分のリソースに関連しないファイルに対してのみ「読み取りアクセス」を持つことになり、クラウドユーザーに権限を割り当てたり取り消したりするより管理しやすいアプローチとなります。DevOpsチームは、ユーザーに219のパーミッションを追加すべきかどうかを手動でチェックすることを期待されていません。マルチクラウド環境の場合、多くの企業は、そもそも付与されるべきでない過剰な権限をユーザーに与えてしまうことになります。

クラウド資産の棚卸し

クラウドでは、「資産」とは何かという定義が劇的に変化しています。従来、資産目録は、サーバー、エンドポイント、ネットワーク機器としてリストアップされていました。もっと簡単に言えば、IPアドレスを持つものすべてが資産でした。最近のクラウドアプリケーションは、もはや単なる仮想化された計算リソースではなく、ビジネスが依存するクラウドサービスのスーパーセットであるため、資産は自動化テンプレートのクレデンシャルと考えることができるようになりました。また、インフラストラクチャー内での起動方法によっては、資産があまりにも刹那的であったり、IPアドレスが取得できなかったりすることがあります。
そのため、クラウドアカウントのクレデンシャルのセキュリティを管理することが不可欠です。エラーや設定ミスは、リソースの停止、ワークロードへの侵入、機密情報の流出、目に見えない資産の作成、あるいはビジネスや評判の低下といったリスクに組織をさらす可能性があります。
最も基本的なレベルでは、Google Cloud、Amazon AWS、Microsoft Azureで確認されているように、クラウドプロバイダーは通常、Cloud Asset Inventoryを提供しています。しかし、クラウド環境を拡張していくと、クラウドプロバイダー内で完結していない何百もの異なるテクノロジーやツール、あるいはクラウドプロバイダーが追加のインサイトを提供するように設計されていない場合、CloudOpsが複雑になりすぎることがよくあります。
このため、クラウド資産のインベントリーをレポートするツールを検討し、企業がCSPMの要件に沿った規制コンプライアンスを容易に維持できるようにすることが重要です。

認証情報の公開を避ける

利用可能なクラウドサービスと構成の数が指数関数的に増加するにつれて、クラウド資産のインベントリチェックを行う必要があります。VM、ワークロード、サービスなどです。
その手始めの1つが、クラウド構成内のプライベートな認証情報の漏洩を防御することです。
シークレットには機密データが含まれるため、安全であるべきであることは前述したとおりです。同じことが、Kubernetes内のConfigMapリソースにも言えます。ConfigMapsを使用すると、環境固有の設定をコンテナイメージから切り離すことができるため、アプリケーションを簡単にポータブルにすることができます。残念ながら、ConfigMapは意図的に非機密データをkey-valueペアで含むように設計されています。しかし、多くの開発者が誤ってConfigMap内にプライベートな認証情報を残してしまい、Kubernetesクラスターが侵害された場合に敵対者によってアクセスされる可能性があります。
以下のFalcoのルールは、ConfigMapがプライベートな認証情報を含んでいる場合に検出するためのものです。発見された場合、これらをコンフィギュレーションファイルから削除してください。
- rule: Create/Modify Configmap With Private Credentials
  desc: >
      Detect creating/modifying a configmap containing a private credential (aws
      key, password, etc.)
  condition: kevt and configmap and kmodify and contains_private_credentials
  output: >-
      K8s configmap with private credential (user=%ka.user.name verb=%ka.verb
      configmap=%ka.req.configmap.name namespace=%ka.target.namespace)
  priority: warning
  source: k8s_audit
  append: false
  Exceptions:
   - name: configmaps
      Fields:
      - ka.target.namespace
      - ka.req.configmap.name

クラウドのクレデンシャルを検索する

最小権限のワークフローで最初に考えるべきことは、インフラストラクチャー・アズ・コード(IaC)テンプレートにイメージスキャンを実装して、設定ミスやパーミッションの間違いでインフラが作成されるのを防ぐ方法です。よく「シフト・レフト」という言葉が飛び交っているのを耳にします。しかし、シフト・レフトとは何でしょうか?
基本的に、シフト・レフト・アプローチは、設計と開発の最も早い段階でセキュリティを統合し、実行時の制御が必要になるずっと前に、しばしばCI/CDパイプラインに重点を置いています。これは、CSPMの中核となる検討事項の1つです。
注:イメージスキャンについてもっと知りたい方は、こちらをご覧ください。 GitLab CI/CDのためのイメージスキャン GitHub Actions によるイメージスキャン
しかし、このブログを読んでいるあなたが、スキャンを実施していない、あるいは、スキャンで設定ミスを検出できなかったと仮定します。本番環境に入り込んでしまった find や grep で取得された資格情報を簡単に検出できるようにすることが重要です。そうしなければ、コンプライアンスや、より重要なセキュリティ姿勢を危うくする可能性があります。
以下のFalcoのルールは、本番環境で公開されているAWSのクレデンシャルを検出するはずです:
- rule: Find AWS Credentials
  desc: Find or grep AWS credentials
  condition: >
    spawned_process and ((grep_commands and private_aws_credentials) or
    (proc.name = "find" and proc.args endswith ".aws/credentials"))
  output: >-
    Search AWS credentials activities found (user.name=%user.name
    user.loginuid=%user.loginuid proc.cmdline=%proc.cmdline
    container.id=%container.id container_name=%container.name evt.type=%evt.type
    evt.res=%evt.res proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid
    proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath
    user.uid=%user.uid user.loginname=%user.loginname group.gid=%group.gid
    group.name=%group.name container.name=%container.name|
    image=%container.image.repository:%container.image.tag)
  priority: notice
  source: syscall
  append: false
  Exceptions:
  - name: proc_pname
    Fields:
    - proc.name
    - proc.pname
  …

IaCスキャン

先に述べたように、IaCテンプレートをスキャンして脆弱性や設定ミスを可能な限り早い段階で発見し、セキュリティ上の懸念が問題になる前に積極的に対処する必要があります。スキャンが必要なIaCテンプレートは、GitHubBitBucketGitLabなどです。Git-integrated スキャンは、以下の種類のファイルやフォルダーに対して実行することができます。YAML、Kustomize、Helm、Terraformが一般的な例です。
スキャンは、あなたが書いたコードに限ったことではありません。多くの場合、ビルドしたことのない一般的なイメージを使用している可能性があります(NginxやCentOSなど)。イメージスキャンは、あなたが使用しているレジストリに対して実行することができるので、イメージが脆弱である場合に警告を受け、そのイメージをデプロイしないための措置を取ることができます。Harborを使用して独自のレジストリをホストしている場合、スキャンを実際のレジストリにビルドすることも可能です。
HarborはオープンソースのCNCFインキュベートプロジェクトで、ハイブリッド環境およびマルチクラウド環境向けに、ロールベースアクセス制御(RBAC)でイメージを保護するコンテナイメージレジストリを提供するものです。
最小権限の要件を満たすために、プライベートレジストリからイメージをプルすることができる人とできない人を制限することは理にかなっています。同様に、Harbor はクラウド ネイティブのコンピュート プラットフォームでイメージを安全に管理することで、マルチクラウド インスタンスのコンプライアンスを実現し、CSPM 要件を満たしています。
Anchoreのチームは、オープンソースソフトウェアのサプライチェーンセキュリティサービス用にHarbor Scanner Adapterを作成しました。このサービスは、HarborのスキャンAPIをAnchoreのコマンドに変換し、Harborが脆弱性スキャン機能の一部としてHarborレジストリに保存されたイメージの脆弱性レポート作成にAnchoreを使用できるようにするものです。これにより、当社のクラウドアプリケーションテンプレートに完全なレポート機能を提供することができるようになります。
apiVersion: apps/v1
kind: Deployment
Metadata:
  name: harbor-scanner-anchore
  Labels:
    app: harbor-scanner-anchore
Spec:
    Spec:
      Containers:
        - name: adapter
        image: anchore/harbor-scanner-adapter:1.0.1
        imagePullPolicy: IfNotPresent
        Env:
          - name: SCANNER_ADAPTER_LISTEN_ADDR
            value: ":8080"
          - name: ANCHORE_ENDPOINT
            value: "http://anchore-anchore-engine-api:8228"
          - name: ANCHORE_USERNAME
            valueFrom:
              secretKeyRef:
                name: anchore-creds
                key: username
          - name: ANCHORE_PASSWORD
            valueFrom:
              secretKeyRef:
              name: anchore-creds
              key: password
          …

次に、K8s クラスターに対して ‘ClusterIP’ タイプで Harbor スキャナ・サービスを公開します。
デプロイマニフェストに指定されているように、スキャナアダプタポートはポート8080でリッスンします。
—
apiVersion: v1
kind: Service
Metadata:
  name: harbor-scanner-anchore
Spec:
  Selector:
    app: harbor-scanner-anchore
  type: ClusterIP
  Ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080

クラウドコンフィギュレーション

IaCテンプレートでイメージがスキャンされ、ビルドプロセスで既知の設定ミスや脆弱性が検出されたと仮定すると、Kubernetesをシールドしてこの種の欠陥がランタイムに入り込むのを防ぐことが重要です。
そこで登場するのが、アドミッションコントローラーです。安全でないテンプレートが承認されるかどうかにかかわらず、ユーザーやワークロードが許可したネットワーク接続が実行時の状態になる前に、最小限の権限を適用するようにクラウドを構成することも検討する必要があります。

Open Policy Agent

Open Policy Agent (OPA) は、クラウド・ネイティブ環境向けにポリシーベースのアドミッションコントロールを提供する、CNCFが主導するプロジェクトです。アドミッションコントローラーは、作成、更新、および削除操作の際にオブジェクトのセマンティック検証を実施します。最小権限原則の場合、本番環境では安全でないテンプレートは許可されるべきではありません。以下のシナリオでOPAを使用することにより、本番環境においてTCPポート443を公開しているワークロードの作成を許可しないようにしています。
match[{"msg": msg}] {
    input.request.operation == "CREATE"
    input.request.kind.kind == "Pod"
    input.request.resource.resource == "pods"
    input.request.object.spec.containers[_].ports[_].containerPort == 443
    msg := "Preventing 443 (TCP) in pod config"
}

これらのパラメータを、クラウド設定の可能な限り早い段階で設定することが重要です。本番環境では明示的に必要とされないポート番号にアクセスしようとするのは、危険なワークロードだけではありません。データ漏洩テストの一環として、外部のC2サーバーと直接通信しようとするユーザーもいるかもしれません。そのため、クラウド環境では、すべてのユーザーからの不要な接続を防止することが重要です。

アイデンティティ・ベースポリシー

アイデンティティ・ベースのポリシーをユーザー・グループにアタッチすることで、すべてのユーザーがポリシーの許可を受けるようにすることができます。AWS上の最小権限の場合、Identity & Access Management (IAM) は、通常Adminsというユーザーグループを持ち、そのユーザーグループに期待される昇格管理者権限を与えることで達成されます。
“non-Admin” ユーザーグループに追加されたユーザーは、自動的にこれらのAdminsグループの期待される権限が取り消されるはずです。
例えば、Network Managerのようなツールからネットワークの活動や構成を見る必要があるフォレンジックチームがいるとします。彼らは仕事をするために、これらすべてのAWSリソースへのアクセスを許可される必要があります。しかし、彼らは実際に何かを構成する必要はありません。彼らの唯一の目的は、アクティビティを監視することです。このユーザーには、Amazon EC2、Network Manager、AWS Direct Connect、CloudWatch、CloudWatch Events APIへの読み取り専用アクセスを許可するIDベースのポリシーを作成することをお勧めします。
これにより、ユーザーはNetwork Managerコンソールを使用して、グローバルネットワークとその関連リソースを表示および監視し、リソースのメトリクスとイベントを表示することができます。ただし、ユーザーはリソースを作成したり、変更したりすることはできません
{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "ec2:Get*",
          "ec2:Describe*"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Allow",
        "Action": [
          "networkmanager:Get*",
          "networkmanager:Describe*"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Allow",
        "Action": [
          "cloudwatch:List*",
          "cloudwatch:Get*",
          "cloudwatch:Describe*"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Allow",
        "Action": [
          "logs:Describe*",
          "logs:Get*",
          "logs:List*",
          "logs:StartQuery",
          "logs:StopQuery",
         "logs:TestMetricFilter",
          "logs:FilterLogEvents"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Allow",
        "Action": [
          "events:List*",
          "events:TestEventPattern",
          "events:Describe*"
      ],
      "Resource": "*"
      },
      {
         "Effect": "Allow",
          "Action": "directconnect:Describe*",
          "Resource": "*"
      }
    ]
}
上記のポリシーでわかるように、このユーザーに関連するIAMは、アスタリスク(*)で示されるように、これらすべてのリソースへのアクセス権を持っています。効果は「許可」に設定されていますが、アクションはほとんどの場合、単に「一覧表示」、「説明」、「取得」になっています。注意すべきは、上記の例はAWSのものであるということです。Microsoft Azureは、少し異なるアプローチでIAMを実装しています。Azure Active Directoryのツリーベースの構造でGroup Policy Object (GPO)を使用します。
とはいえ、ここに見られるように、Microsoft Azureは問題なく動作します。一方、Google Cloudは、allowポリシーがプリンシパルをIAMロールにバインドするこの単純な例で見られるように、Amazon AWSと同様のワークフローを提供します。
{
  "bindings": [
    {
      "members": [
        "user:nigeldouglas@falco.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMHhHNvY=",
  "version": 1
}
上の例では、nigeldouglas@falco.com に ‘Owner’ という基本ロールが無条件に与えられています。このロールは、ユーザー ‘nigel’ にほぼ無制限のアクセス権を与えています。このユーザーが全権限を持つことに非常に明確なビジネス上の正当性がない限り、AWSで見たようなルールを作成して、このユーザーのアクセスを制限すべきです。
AWSのIDベースのポリシー(リソースベースのポリシーなど)では、ユーザーグループをPrincipalとして特定できないことに注意することが重要です。グループは認証ではなく、権限に関連し、Principalは認証されたIAMエンティティだからです。

リソースベースポリシー

リソースベースのポリシーは、リソースにアタッチされる。たとえば、Amazon S3バケット、Amazon SQSキュー、VPCエンドポイント、およびAWS EC2インスタンスにリソースベースのポリシーをアタッチすることができます。リソースベースのポリシーは、ポリシーで指定されたプリンシパルにパーミッションを付与します。
このタイプのポリシーは、組織が、ポリシーがアタッチされているリソースからAPIを呼び出すことができる人/ものを指定するのに役立ちます。こうすることで、インフラストラクチャーレベルのサービスプリンシパルがLambdaのサーバーレス機能を呼び出したり管理したりするのを防ぐことができます。
以下のマニフェストを見れば、クラウドリソースに最小権限原則を実装するイメージが湧くはずです。
"Version": "2022-10-17",
"Id": "default",
"Statement": [
    {
      "Sid": "lambda-allow-s3-nigel-function",
      "Effect": "Allow",
      "Principal": {
        "Service": "s3.amazonaws.com"
      },
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:us-east-2:123456789012:function:my-function",
      "Condition": {
        "StringEquals": {
          "AWS:SourceAccount": "123456789000"
        },
        "ArnLike": {
          "AWS:SourceArn": "arn:aws:s3:::nigel-bucket"
        }
      }
    }
]

ネットワーク制限の遵守

ネットワークのセキュリティ制御を行うには、様々な方法があります。
全体として、Amazon AWSやGoogle CloudではSecurity Group(SG)を、Microsoft AzureではNetwork Security Group(NSG)と呼ばれるものを作成することができます。オンプレミスで独自のファイアウォール・ソリューションの背後にすべてを管理している場合でも、クラウドのセキュリティ・グループという形で仮想ファイアウォールを実装している場合でも、インフラストラクチャーと公衆インターネットとの間の通信を制限する必要があるのです。
特定のポート、プロトコル、または宛先IPを明示的に開く必要がない場合は、それらをシャットダウンしてしまいましょう。
CSPMは、インフラストラクチャーレベルでネットワーク制御を適用することを推奨しています。AWS cloudtrail メタデータを Falco に取り込むことで、VPC 固有のネットワーキング活動に対してアラートを出すことができます。最小権限設計を観察する良い例は、Ingressトラフィックがパブリックインターネットに開放されているネットワークアクセス制御リスト(ACL)の作成にアラートすることです。クラウドトラフィックをオープンインターネットに開放する特別な理由がない場合、これらの ACL 条件を制限する必要があります。以下は、このルールのFalcoのテンプレートです:
- rule: Create a Network ACL Entry Allowing Ingress Open to the World
  desc: >-
    Detect creation of access control list entry allowing ingress open to the world.
  condition: |
      aws.eventName="CreateNetworkAclEntry" and not aws.errorCode exists and (
        not (
          jevt.value[/requestParameters/portRange/from]=80 and
          jevt.value[/requestParameters/portRange/to]=80
       ) and
      not (
        jevt.value[/requestParameters/portRange/from]=443 and
        jevt.value[/requestParameters/portRange/to]=443
      ) and
      (
        jevt.value[/requestParameters/cidrBlock]="0.0.0.0/0" or
        jevt.value[/requestParameters/ipv6CidrBlock]="::/0"
      ) and
      jevt.value[/requestParameters/egress]="false" and
      jevt.value[/requestParameters/ruleAction]="allow"
    )
  output: >-
    Detected creation of ACL entry allowing ingress open to the world
    (requesting user=%aws.user, requesting IP=%aws.sourceIP, AWS
    region=%aws.region, arn=%jevt.value[/userIdentity/arn], network acl
    id=%jevt.value[/requestParameters/networkAclId], rule
    number=%jevt.value[/requestParameters/ruleNumber], from
    port=%jevt.value[/requestParameters/portRange/from], to
    port=%jevt.value[/requestParameters/portRange/to])
  priority: error
  source: aws_cloudtrail
  append: false
  exceptions: []

まとめ

Gartner 社の CSPM の定義によると、プラットフォームはクラウド コントロール プレーンに関わるものであり、そのコントロール プレーンで実行されるクラウド ワークロードに関わるものではありません。最小権限の原則をクラウドコントロール プレーンに適用することで、潜在的に悪意のある設定や、意図しない誤設定によって攻撃者が環境を侵害したり機密データへのアクセスを容易にする可能性があることをより迅速にレポートすることができます。
ネットワーク、イメージスキャン、ユーザー権限、ユーザー認証に同じ最小権限の概念を設定することで、攻撃者がクラウド環境に侵入する前に検出し、より重要な防止策を講じることができるはずです。
CSPM は、このシフトレフトの方法論に焦点を当てています。 強力なポスチャー管理には、ゼロトラスト セキュリティを全体的に検討する必要があります。 これらのガードレールが構成されたら、監視ツールとオブザーバビリティ ツールを使用して、意図したセキュリティ体制から逸脱する可能性があることを通知できます。
もし、実際に発生している脅威の特定と検出だけに焦点を当てるのであれば、セキュリティ情報&イベント管理(SIEM)やセキュリティの自動化、オーケストレーション&レスポンス(SOAR)プラットフォームを導入する方がより理にかなっています。一方、本番環境における生の脅威の防御を目的とする場合は、エンドポイント保護プラットフォーム(EPP)や侵入防御システム(IPS)を導入することができます。
最後に、CSPMをクラウドワークロード保護プラットフォーム(CWPP)と混同しないようにしましょう。CSPMは、アプリケーション・レベルのセキュリティ・リスクに対処するためのものではありません。例えば、ソースコードやコンテナ・イメージをスキャンして脆弱性を検出することはありません。そこで、ソースコード解析、イメージスキャナー、および同様のツールが活躍することになります。
上記のように、CSPMプラットフォームの基盤として、無数に存在するオープンソースツールを使用することができます。CSPM の最小権限原則を適用する場合、更新されたユーザー認証情報、強力なネットワーク・ルール、およびクラウド環境で潜在的に開示された認証情報/誤設定に関するアラートによって、ユーザーの侵害を抑制または防止することができます。クラウドの監査ログから安全でない状態を検出することで、管理者はクラウドアカウントのセキュリティ姿勢を改善するための積極的な措置を取ることができます。
しかし、CSPMは問題の一部にしか対処していません。CSPMによる全体的なポスチャー管理の評価と、ワークロード・レベルの最小権限ポリシーおよび検出を組み合わせることで、エンドツーエンドのクラウド検出および対応(CDR)ソリューションを提供することが可能になります。
クラウドセキュリティの基礎知識については、Sysdig Secureのホワイトペーパーをご覧ください。