🎁

AWSのコンテナセキュリティを考えるoverview

2024/09/16に公開

はじめに

この記事は、AWSでコンテナ実行環境を構築する際に考える必要があるセキュリティの項目とその内容や利用サービスについて私自身が整理するためのものです。
けして網羅的ではなく、自分用overviewとしてのまとめ記事なので、抜け漏れはあります。また解説も詳しくはしておらず、ワードの羅列により自分なりにインデックスを作ることを目的としています。

参考

https://aws.amazon.com/jp/blogs/news/aws-black-belt-online-seminar-container-security-introduction/
https://pages.awscloud.com/rs/112-TZM-766/images/202106_AWS_Black_Belt_Containers130-Security.pdf

イメージの開発

安全なイメージであるか。
安全なイメージとは?

信頼できるレジストリの信頼できるイメージを使用する

  • なぜ?
    • 信頼できないレジストリ・イメージは脆弱性やマルウェアが含まれている可能性がある
    • 信頼できるレジストリではセキュリティスキャンやレビューが定期的に行われており、既知の脆弱性が含まれたイメージを避けることができ、セキュリティリスクの減少につながる。
  • 関連ワード
    • イメージの整合性・信頼性 / 署名付きイメージ / イメージのバージョン管理
    • サプライチェーン攻撃の防止
    • コンプライアンスの確保
    • 品質・パフォーマンスの一貫性

実行時にパッケージをインストールしない

  • なぜ?
    • 予期しない脆弱性の可能性
    • 再現性の確保が難しくなる
    • セキュリティ管理が複雑になる

イメージを小さく保つ

  • なぜ?
    • 攻撃対象を最小化
      不要なパッケージやライブラリが含まれていると、それらが攻撃に利用される不要なリスクとなる。
      脆弱性の潜在する範囲・可能性が大きくなる。
    • 管理のしやすさ
      不要なパッケージやライブラリを含まないことで脆弱性スキャンやパッチ運用の対象が減る。脆弱性の把握・対処が効率的になる。
      結果としてセキュリティを維持しやすくなる。
  • 方法
    • 小さなベースイメージの使用
    • マルチステージビルドの活用

コンテナの実行権限

USERを指定する。未指定の場合、コンテナがrootで実行される。

シークレットをコンテナイメージに埋め込まない

もしイメージ開発の過程で(Dockerfile内で)シークレットが必要であれば、rmを忘れない。

lintツールを使用する

ビルド時

  • Docker daemonはrootのプロセス

    • docker runできるユーザーはrootとしてホストマシンを操作できる
    • 関連ワード
      • rootless
  • ビルド環境はマネージドサービスを使用する(自分で管理しない)

    • AWS CodeBuild
    • ビルド用SaaSサービス

脆弱性対応

Amazon Inspectorの活用。

基本的な対応ルール

  • イミュータブル
    スキャンしたイメージと同一のものが実行されていること
  • 定期的なスキャン・デプロイ
    デプロイされているのはセキュリティパッチが適用されたイメージであること

脆弱性スキャンの注意点

  • 未対応の場合、未知の場合
  • スキャン対象の範囲

何をどのくらいスキャンしているか、またスキャンを絶対視しないこと。

サプライチェーンの保護

安全なレジストリから安全なイメージを安全な経路でコンテナに。

レジストリの保護

ECRへのアクセス制御

オーケストレータの保護

ネットワークの保護

許可したネットワークからのみアクセスする。

ユーザーと権限の管理

アクセスできるユーザーの適切な管理。SSOの使用。
また権限は最小限に絞って付与。

ホストの保護

コンテナはKernelを共有している。
→Kernelに脆弱性があると、コンテナからエスケープできるリスクがある。
分離の強化により保護。

seccompによる分離

= secure computing mode
コンテナに不要なシステムコールを制限する。

Linux Security Module(LSM)

SELinux, AppArmorでコンテナがアクセスできるリソースを制限する。

カーネル分離

そもそもカーネルを共有しない。
Fargateは簡単にカーネルの分離を実現。

実行時の保護

ネットワークセキュリティ

コンテナ間通信のポリシー定義。
ECSタスクやKubernetesのPodに割り当てるセキュリティグループ
KubernetesのNetwork Policy、アプリケーションレベルの保護

データを保護する

  • ノード、コンテナインスタンスの暗号化
    • EC2で暗号化を有効にする
    • Fargateはデフォルトで暗号化
  • 外部ストレージの暗号化
    • EFS
    • EBS
  • シークレット、パラメータの取り扱い

ランタイムセキュリティ

GuardDutyによるランタイムセキュリティの脅威検知

https://aws.amazon.com/jp/blogs/news/introducing-amazon-guardduty-ecs-runtime-monitoring-including-aws-fargate/

まとめ

一言で

ライフサイクル・フェーズごとに保護・対策を検討する。

GitHubで編集を提案
Fusic 技術ブログ

Discussion