〜セキュリティ課題、溜め込んでいませんか？〜 カミナシにおける AWS Security Hub CSPM との向き合い方

こんにちは、「カミナシ レポート」の開発に携わっている furuya です。
今回はみんなだいすき AWS Security Hub CSPM に対する、カミナシのサービスチームの向き合い方についてご紹介します。

AWS Security Hub CSPM とその通知用社内システムについて

AWS Security Hub CSPM とは

今年（2025/6）の AWS re:Inforce にて、AWS Security Hub サービスの再構成がアナウンスされました。今までおなじみだった AWS Security Hub 相当のものは AWS Security Hub CSPM という名前に変わっています。CSPM とは Cloud Security Posture Management の略で、AWS リソースのセキュリティ設定がベストプラクティスから逸脱していないかを管理するサービスです。

検出されたものを溜め込みがち問題

AWS Security Hub CSPM ではセキュリティチェックの結果が確認できます。重大度が CRITICAL や HIGH のものはなるべく対処しておきたいところですが、なかなか対応する工数が取れなかったり優先度が上がらなかったりしてどんどん溜まっていく一方…どうやって対処しようか…というお話をよく聞きます。

カミナシにおけるリスク評価と対応方針

カミナシでは AWS Security Hub CSPM だけでなく、ライブラリ・ミドルウェアの脆弱性も含めて、検出されたものへの対応方針をルールとして明確にしています。たとえば重大度に応じて対応スケジュールが決まっており、HIGH だとxx日以内、というようなものです。これによってセキュリティ課題を溜め込まない仕組みになっています。もちろんルールを作っただけではダメで、開発者がセキュリティに対してオーナーシップを持てるような文化づくりも合わせて必要です。そのあたりは割愛しますが、気になる方は西川さんの記事をご覧ください。

kaminashi-developer.hatenablog.jp

脆弱性通知・管理のための社内システム、Liver（レバー）

脆弱性に対して立ち向かうルールと文化に加えて、それらを通知・管理する仕組みが必要です。その仕組みとして Security Engineering では Liver（レバー） というシステムを運用しています。Liver は肝臓を意味しますが、大事だけど食べ物としては嫌いな人もいがち = セキュリティに似ている、というところから命名されています。
Liver の詳細はこちらも西川さんの発表資料をご覧ください。

speakerdeck.com

Liver で通知された Security Hub findings は CRITICAL や HIGH であれば何も考えずに対応するというものではなく、その内容が自分たちのプロダクトにどのように影響するのかをまず見極めなければなりません。HIGH で検知されたものでも実際は他の場所でセキュリティリスクが軽減されていれば優先度を一時的に下げるという判断が可能になります（もちろんその後適切に対処するという前提ですが）。サービスを開発・運用している開発者がリスクを理解し、ルールも考慮してコントロールできることがダイジだと考えています。

Liver 第二段階へ

HIGH も検知対象にしたい

導入当初は重大度が CRITICAL のものが検出された場合に、当該AWSアカウントを管理しているサービスチームへ通知するようにしていました。上記の資料でも言及されていますが、これにより CRITICAL の検出は撲滅できました。次の段階として HIGH のものについても通知対象に含めることになりました。

進め方

いきなり全チームに展開すると混乱を生む可能性がある & 1つのチームで先行して HIGH に対処できれば他のチームが参考にできる、ということで資料p.18に記載されているようにRamp-up期間を設け、かつモデルケースとして「カミナシ レポート」で管理しているAWSアカウントでお試し運用、もとい HIGH の撲滅活動を行いました。

対応の具体例

[ECS.5] ECS コンテナは、ルートファイルシステムへの読み取り専用アクセスに制限する必要があります。
https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/ecs-controls.html#ecs-5

このコントロールは、Amazon ECS コンテナがルートファイルシステムへの読み取り専用アクセス権を持っているかどうかをチェックします。readonlyRootFilesystem パラメータが に設定されている場合false、またはタスク定義内のコンテナ定義に パラメータが存在しない場合、コントロールは失敗します。このコントロールは、Amazon ECS タスク定義の最新のアクティブなリビジョンのみを評価します。

「カミナシ レポート」はバックエンド API のコンピューティング環境として ECS Fargate を利用しており、今回いくつかの ECS タスク定義において上記が検出されました。対応としては記載のとおり ReadonlyRootFilesystem パラメータを true にするだけなのですが、一様に書き込みを禁止してしまうとアプリケーション以外のところ、たとえば ECS Exec や Datadog Agent が意図したとおり動かなくなるケースがありました。その対処法についてシェアします。

ECS Exec
トリさんが以前ブログで対処法を公開しています。

toris.io

このワークアラウンドは引き続き有効なので、ReadonlyRootFilesystem を true にしつつ ECS Exec したい方は設定必須です。引用すると、/var/lib/amazon と /var/log/amazon のディレクトリを書き込み可能にしてあげる必要があります。以下はタスク定義での書き方の例です。

{
  ...
  "containerDefinitions": [
    {
      ...
      "mountPoints": [
        {
          "sourceVolume": "var-lib-amazon",
          "containerPath": "/var/lib/amazon",
          "readOnly": false
        },
        {
          "sourceVolume": "var-log-amazon",
          "containerPath": "/var/log/amazon",
          "readOnly": false
        }
      ],
      ...
    },
    ...
  ],
  ...
  "volumes": [
    {
      "name": "var-lib-amazon",
      "host": {}
    },
    {
      "name": "var-log-amazon",
      "host": {}
    }
  ],
  ...
}

Datadog Agent
「カミナシ レポート」の API サーバーではメトリクスの取得や APM のために Datadog Agent をサイドカーコンテナとして配置しています。こちらも同様に一部のディレクトリを書き込み可能にしないと Agent が起動できません。また、それだけだと Datadog 上で ecs.fargate.cpu.usage などの Fargate 用のメトリクスがとれなくなってしまうので、以下記載の通りに dockerLabels も設定してあげる必要があります。

{
  ...
  "containerDefinitions": [
    {
      ...
      "mountPoints": [
        {
          "sourceVolume": "dd-agent-etc-datadog-agent",
          "containerPath": "/etc/datadog-agent",
          "readOnly": false
        },
        {
          "sourceVolume": "dd-agent-opt-datadog-agent-run",
          "containerPath": "/opt/datadog-agent/run",
          "readOnly": false
        },
        {
          "sourceVolume": "dd-agent-var-run-datadog",
          "containerPath": "/var/run/datadog",
          "readOnly": false
        }
      ],
      ...
      "dockerLabels": {
        "com.datadoghq.ad.init_configs": "[{}]",
        "com.datadoghq.ad.instances": "[{}]",
        "com.datadoghq.ad.check_names": "[\"ecs_fargate\"]"
      },
      ...
    },
    ...
  ],
  ...
  "volumes": [
    {
      "name": "dd-agent-etc-datadog-agent",
      "host": {}
    },
    {
      "name": "dd-agent-opt-datadog-agent-run",
      "host": {}
    },
    {
      "name": "dd-agent-var-run-datadog",
      "host": {}
    }
  ],
  ...
}

ReadonlyRootFilesystem は上記のように工夫が必要だったのと、ボリュームへの書き込みを禁止することからアプリケーションの動作確認も念の為しておいたほうがよさそう、ということで対応には期間を要しました。その合間で他に検知されていた HIGH のものを対応もしくは対応の目処をたて、無事に HIGH findings の撲滅は完了しました。

全社展開

上記のような対処法および具体的な Terraform コードを添えて、HIGH の検知を開始する旨を予告しました。具体的な対処法が添えられていることで再調査の工数なく各チームに対応してもらっています。

まとめ

カミナシにおける AWS Security Hub CSPM との向き合い方をご紹介しました。開発者が主体となってセキュリティに対応するために、適切なルール設定と仕組みづくりを行うことで持続可能、かつコントローラブルな環境を実現しています。この取り組みがみなさんの開発チームにおけるセキュリティ向上の参考になれば幸いです。