PCI DSSで学ぶAWSセキュリティ④ ~Amazon EKS(マネージドコンテナサービス)の設計~

セキュリティ

2022.07.13

  

前回(https://www.intellilink.co.jp/column/security/2021/102200.aspx)までにクレジットカード業界のセキュリティ基準であるPCI DSSをベースにAWSプラットフォーム上でセキュアにシステムを構成する際の留意点について、セグメンテーションによる環境分離、責任共有モデルに基づいた利用者の責任範囲の理解、各要件に沿ったセキュリティ対策のポイントについて紹介してきました。
今回は、コンテナサービスを管理するためのプラットフォームであるKubernetesをマネージドサービスとして提供するAmazon Elastic Kubernetes Service(Amazon EKS)をセキュアに構成するための留意点についてAWSから公開されているガイダンス文書「Architecting Amazon EKS for PCI DSS Compliance」[1]をもとに概説します。コンテナベースのサービスはOSやネットワークが共用されるため、単一のオペレーティングシステムで複数コンテナを実行するような場合、すべてのコンテナにアクセス可能な共通の攻撃ポイントを攻撃者に提供することになりかねません。そこで、このようなセキュリティリスクを低減するための対策についてAWSサービスを中心とした構成例をみていきましょう。

ホストOSとコンテナイメージの強化

Amazon EKSでは、コンテナの実行環境となるWorker NodeのホストOS上で、複数の関連するコンテナを含むPODという単位で処理が実行されます。またPOD内で稼働するコンテナは、アプリケーション実行に必要なものをすべて含んだソフトウェアパッケージであるコンテナイメージをデプロイすることで稼働させます。そのため、Worker NodeのホストOSに加えて、コンテナイメージをセキュアに構成することが必要です。ガイダンスでは下記のような対策が推奨されています。

  • Worker Node上のホストOS(図1-①参照)
    • セキュリティパッチの適用やマルウェア対策などシステムの堅牢化
    • Amazon Inspectorなどを活用した脆弱性評価と対処
    • マネージドサービスであるAWS Fargateによりパッチ適用などの管理負担を軽減
  • コンテナイメージ(図1-②参照)
    • 信頼できるコンテナイメージを使用
    • Amazon ECRなど信頼できるコンテナレジストリを使用
    • Amazon InspectorによるAmazon ECRでのコンテナスキャンおよび対処

図1:ホストOSとコンテナイメージの強化ポイント
図1:ホストOSとコンテナイメージの強化ポイント

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

AWSアカウントやVPCネットワークを分けて他の環境から分離したり(図2-①参照)、Internetなど他のネットワークからの通信をAWS Network FirewallやVPCセキュリティグループを用いて必要最小限に制限したり(図2-②参照)することが基本の対策です。加えて、Amazon EKSを利用したコンテナベースのサービスを提供するにあたっては、以下のような各レイヤーでの対策が考えられますが、POD間通信を細かく制御するのか、あるいは複雑化を避けるためにセキュリティレベルに応じたノード分割によりノード間でネットワークアクセス制御を実現するのかなど、システムの特徴に応じて最適な考え方を採用することが重要です。

  • コントロールプレーンとの通信(図2-③参照)
    • VPCセキュリティグループによりコントロールプレーンとノード間通信を制限
  • ノード間通信(図2-④参照)
    • セキュリティレベルに応じてノードを分けて、それぞれ専用のVPCセキュリティグループを使用して分離
  • POD間通信/PODと外部サービス間通信(図2-⑤参照)
    • デフォルトではすべてのポッド間通信がクラスター内で許可されるため、必要な場合、Kubernetesネットワークポリシーなどを用いてポッド間通信を制限
    • PODのセキュリティグループなどによりクラスター外のサービスとポッド間の通信を制限

図2:ネットワークセキュリティの構成例
図2:ネットワークセキュリティの構成例

データ保護

コンテナで取扱う機密データは、安全なファイルストアやデータベースにのみ保存してファイルシステムのボリュームマウントなどによってホストOS上に意図せず保存してしまわないよう注意が必要です(図3-①参照)。また、コンテナのイメージやビルドファイルに含まれるデータベース接続認証情報などのパスワード文字列や環境変数はAWS KMSなどを用いて暗号化保存することで、平文のままのパスワード文字列を含むファイルがGitHubを介して流出してしまうような事故の予防につながります(図3-②参照)。さらに、転送中の機密データも保護することで機密データの流出ポイントを最小化できます。ALBを介した外部とのデータ転送や、データベースなど重要なリソースとの接続時のhttpsを強力な暗号化構成で保護するだけでなく、可能な限りポッド間通信についてもmTLSなどのプロトコルを有効化して暗号化することが推奨されます(図3-③参照)。

図3:データ保護のポイント
図3:データ保護のポイント

アクセス制御

各種リソースへのアクセスを業務上必要な最小限のアクセスに制限することが必要です。コンテナベースのサービスでは前述のネットワークセキュリティ同様に以下のような複数のレイヤーで適切なアクセス制御を講じることが対策のポイントです。

  • コンテナ/ホストOS/レジストリ
    • root以外のユーザーアカウントでコンテナを実行(図4-①参照)
    • EC2起動タイプのホストOSへのsshでの直接アクセスは無効化し、AWS Systems Manager Run Commandなどで代替(図4-②参照)
    • AWS Identity and Access Management(IAM)によるECRなどコンテナレジストリのアクセス制限(図4-③参照)
  • Amazon EKS(IAM/Kubernetes RBAC)
    • 専用IAMロールを使用してクラスターを作成し、原則通常業務には使用せず、使用状況を定期的に監査(図4-④参照)
    • aws-auth ConfigMapを介して追加ユーザーにクラスターへのアクセスを許可し、Roles/RoleBindings(名前空間)とClusterRole/ClusterRoleBindings(クラスター)を作成して最小限の権限を付与(図4-⑤参照)
    • 可能な場合、IRSA(IAM Roles for ServiceAccout)を使用してPOD単位でIAMロールを割当て(図4-⑥参照)

図4:アクセス制御の構成例
図4:アクセス制御の構成例

まとめ

今回は、AWSのマネージドコンテナサービスであるAmazon EKSをセキュアに構成するための留意点についてガイダンス文書からポイントを抜粋して紹介しました。今回紹介した対策以外にもログの保全やモニタリング、定期的なセキュリティテスト実施などPCI DSSの各要件に沿った多層的なセキュリティ対策が必要となる点はコンテナサービスを利用する場合も同様です。加えて、脆弱な状態のコンテナイメージが本番環境にデプロイされて攻撃者の侵入を許してしまうなどコンテナ固有のリスクを認識した上で、一連のコンテナのデプロイメントサイクル全体にわたってイメージやレジストリ、ホストOS、コントロールプレーンなど各レイヤーでの対策を講じることが重要となります。今回紹介しましたポイントを参考に、PCI DSSなどのコンプライアンス要件への遵守、コンテナ環境のセキュリティ向上につながるよう、継続的な対策に取り組んでいただけましたら幸いです。

参考リソース

お問い合わせ

AWSなどのパブリッククラウド環境のセキュリティについてまずは現状把握が重要です。セキュリティ基準に基づいたアセスメントサービス、各種セキュリティ診断サービスなどでのご支援が可能です。また、最新のPCI DSS Version4.0に対応できるサービスも提供しております。お気軽にお問い合わせください。
「PCI DSSトータルサービス」を刷新 | NTTデータ先端技術株式会社 (intellilink.co.jp)
お問い合わせフォーム https://www.intellilink.co.jp/contact-us.aspx

※Amazon Web Services、「Powered by Amazon Web Services」ロゴ、およびかかる資料で使用されるその他のAWS商標は、米国および/またはその他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。

PCI DSSで学ぶAWSセキュリティ④ ~Amazon EKS(マネージドコンテナサービス)の設計~