サイト内検索
サイト内検索を閉じる

AWS Fargate環境におけるNIST SP800-190対応についての検討

ビジネスにおいて柔軟性や速度が重要になってきた昨今において、アジャイル開発やDevOpsといった開発・運用方式に多くの企業が本格的に取り組んでおります。それらを実現する技術の一つとして、WEBシステムを中心に様々な場面で活用されているのが“コンテナ技術”です。しかし一方で、新しいテクノロジーである“コンテナ技術に関するセキュリティ対策”は周知がされておらず、セキュリティ面をあまり考慮せずにコンテナ環境を利用しているケースが多く見受けられます。
アメリカ国立標準技術研究所（NIST）が発行しているSP800-190（Application Container Security Guide）はコンテナ環境に対するセキュリティガイドラインとなっています。本記事では、代表的なクラウドサービスであるアマゾン ウェブ サービス（AWS）のコンテナ環境用のサービスであるAWS Fargate上で、NIST SP800-190 にどう対応していくのか検討した内容をご紹介していきます。

NIST SP800-190（Application Container Security Guide）とは

IT分野におけるセキュリティ基準を含む様々なガイドラインを定義しているアメリカ国立標準技術研究所（NIST）が発行したガイドになり、コンテナ環境上にシステム（アプリ）を構築する際に考慮すべきセキュリティリスクが定義されています。

ガイドでは、主に以下のような内容が記載されています。

  1. コンテナ技術の概要/アーキテクチャ
  2. コンテナ技術のコアコンポーネントにおける主なリスク
  3. 主なリスクへの対策
  4. コンテナ脅威の例

※参考
NIST Special Publication 800-190（日本語翻訳）：https://www.ipa.go.jp/files/000085279.pdf
NIST Special Publication 800-190（原本）：https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf

コンテナ技術のコアコンポーネント

コンテナ技術を用いた環境においては様々なコンポーネントが存在しますが、NIST SP800-190でコアとされているコンポーネントは以下の通りです。

①コンテナイメージ 仮想マシンイメージのコンテナ版。コンテナの元となるテンプレート。コンテナイメージをデプロイしてコンテナを稼働させる。デファクトはDockerイメージで公式リポジトリなどから取得するか、Dockerfileをビルドすることで作成できる。
②コンテナレジストリ コンテナイメージを保管・管理するリポジトリ。AWSではAmazon Elastic Container Registry (ECR)
③コンテナオーケストレータ コンテナイメージからコンテナのデプロイ、稼働後のコンテナの運用・管理などで利用されるツール。Kubernetesなどが代表的なコンテナオーケストレータで、AWSではKubernetesのマネージドサービスであるAmazon EKS(Amazon Elastic Kubernetes Service)、Amazon ECS(Amazon Elastic Container Service)。
④コンテナ 仮想化されたアプリ動作環境。コンテナイメージをデプロイして作成する。
⑤ホスト コンテナが稼働するコンピューティング環境。サーバ、仮想マシン、クライアントコンピュータなど様々な環境を利用できる。Amazon EC2上か、AWS Fargateと呼ばれるAWSマネージド環境のどちらかを利用するのが主流でその他外部環境（EXTERNAL）も利用できる。

コアコンポーネントにおけるセキュリティリスク

IST SP800-190においては、先述したコアコンポーネント毎に想定されるセキュリティリスクが明示されています。ここからは、各コンポーネントにおけるセキュリティリスクについて、簡単に紹介していきます。
※詳細についてはNIST SP800-190の「3.コンテナ技術のコアコンポーネントの主なリスク」をご参照ください。

①コンテナイメージにおけるリスク

イメージの脆弱性 イメージ内のコンポーネントが古い、重要なセキュリティアップデートが未適用の状態など
イメージの設定の不備 イメージにSSHデーモンが含まれている、不必要に大きな権限（root）などでコマンドが実行されているなど
埋め込まれたマルウェア イメージに悪意のあるファイルが含まれているなど
埋め込まれた平文の秘密情報 シークレット情報が平文で書き込まれているなど
信頼できないイメージの使用 提供元が不明なイメージや十分な検証がされていないイメージを使用しているなど

②コンテナレジストリにおけるリスク

レジストリへのセキュアでない接続 レジストリに平文の通信で接続しているなど
レジストリ内の古いイメージ 多くの脆弱性が含まれた古いイメージがレジストリに保管されており、コンテナとしてデプロイしてしまう可能性があるなど
認証・認可の不十分な制限 認証・認可の設定がされておらず想定外の第三者がアクセスできる状態になっているなど

③コンテナオーケストレータにおけるリスク

制限のない管理者アクセス 本来アクセスを許可する必要がないコンテナにもアクセスできるような権限を利用者に付与してしまっているなど
不正アクセス オーケストレータ―にアクセスするユーザのセキュリティポリシーが脆弱になっており、第三者に乗っ取られやすい状況となっているなど
コンテナ間ネットワークトラフィックの不十分な分離 異なるシステム/コンポーネントが稼働するコンテナ間のネットワークが正しく分離できておらず、コンテナ間・システム間不必要な通信が可能な状態になっているなど
ワークロードの機微性レベルの混合 同一ホスト上で外部公開サーバと機密情報を持つDBなどが稼働し、外部公開サーバに重大な脆弱性が存在した場合にDBも攻撃にさらされる可能性が高くなるなど
オーケストレータノードの信頼 オーケストレータ―の設計・設定不備により、不正なホストの稼働、各ホストの認証鍵の共有など他のコンポーネントのセキュリティリスクが高まるなど

④コンテナにおけるリスク

ランタイムソフトウェア内の脆弱性 コンテナ経由でランタイムソフトウェアの脆弱性を突かれ管理する他のコンテナにも被害が広がるなど
コンテナからの無制限のネットワークアクセス コンテナが乗っ取れた場合にネットワークアクセスが制限されていないことでネットワークをスキャンされてしまうなど
セキュアでないコンテナランタイムの設定 コンテナからホストOSに対して不必要な操作ができる状態になっており、コンテナが乗っ取られた場合に当該権限を用いてホストOSまで攻撃を受けてしまうなど
アプリの脆弱性 稼働するアプリ自体の脆弱性を突いた攻撃（クロスサイトスクリプティングなど）を受けることや、コンテナ内でマルウェアが保存・実行されてしまうなど
未承認コンテナ 稼働予定がないコンテナや検証されていないコンテナを誤りもしくは悪意を持って稼働し、攻撃の対象となってしまうなど

⑤ホストOSにおけるリスク

大きなアタックサーフェス ホストOSは物理サーバや仮想マシン上で稼働するためコンテナと比べて攻撃にさらされるリスクが高い
共有カーネル コンテナOSはアタックサーフェスが小さいが、共有カーネルを利用することでアタックサーフェスが大きくなる
ホスト OSコンポーネントの脆弱性 ホストOSの脆弱性を突いた攻撃を受け、ホストOSで稼働するコンテナ及びアプリにも影響が発生するなど
不適切なユーザアクセス権 本来は特定のコンテナに接続するだけのユーザに誤ってホストOSへのアクセス権を付与してしまうことで、その他のコンテナに影響を与えてしまう可能性があるなど
ホストOSファイルシステムの改ざん ホストOSのディレクトリをコンテナにマウントしている場合、ホストOS上のファイル改ざんによってコンテナの動作にも影響が発生するなど

AWS Fargate環境におけるコアコンポーネントのセキュリティ対策

AWS FargateはAWSが提供しているコンテナ向けのマネージドサービスになります。AWS　Fargateの詳細な説明は本記事では割愛させていただきますが、コンテナホスト（データプレーン）の管理が不要となることから、AWS上でコンテナ環境を構築する場合、まずAWS Fargateを検討されるというケースが多くなっています。このAWS FargateとAmazon ECS/Amazon EKSを用いてコンテナ環境において、「コアコンポーネントにおけるセキュリティリスク」で記載した各リスクに対して、どのようなセキュリティ対策が必要となるかについて検討してみました。

①コンテナイメージにおけるリスク

  • イメージの脆弱性
    Amazon ECRを用いることでECRのイメージスキャン機能にてコンテナイメージに内在する脆弱性を特定可能です。システムのセキュリティ要件やコストに応じてベーシックスキャン、拡張スキャンを選択できます。
    https://docs.aws.amazon.com/ja_jp/AmazonECR/latest/userguide/image-scanning.html
  • イメージの設定の不備
    本リスクはコンテナイメージ自体ではなく、Dockerファイルからコンテナイメージをビルドする前に確認するような運用が必要になってきます。（規定、ガイドラインを設けて手動or 自動でチェックするなど）
    セキュリティ面以外にもDockerファイルを記述するうえでのベストプラクティスがdocker docsに記載されています。
    https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

    公式なツールではありませんが、一部のベストプラクティスに対応しているかをチェックするツールがGitHub上でも公開されていますので、このようなツールの活用も検討できます。また、3rd Partyのコンテナセキュリティ製品を採用する場合には、脆弱性と合わせて一部のイメージ設定の不備をスキャンする製品も存在します。
  • 埋め込まれたマルウェア
    本リスクに対してはAWS機能や運用のみで対応するのは困難になってきます。対策を行う場合にはコンテナのセキュリティ対策に対応した3rd Party製品の導入を検討する必要があります。
  • 埋め込まれた平文の秘密情報
    本リスクについてもDockerファイルの時点で確認するような運用が必要になってきます。こちらも非公式ながらもチェックできるツールもあるようです。また、3rd Partyのコンテナセキュリティ製品で対応している場合もあります。
  • 信頼できないイメージの使用
    本リスクは利用するコンテナイメージについて、ガイドラインなどを設けて運用をしていく、コンテナをデプロイする際のレジストリを厳格に管理するなどの対応が必要です。

②コンテナレジストリにおけるリスク

③コンテナオーケストレータにおけるリスク

  • 制限のない管理者アクセス
  • 不正アクセス
    これらのリスクについてもAWS IAMによってAmazon EKSやAmazon ECSの操作権限を正しく（必要最低限で）ユーザに割り振ることで対応できます。
  • コンテナ間ネットワークトラフィックの不十分な分離
    こちらは設計にて対応が必要な範囲となりますがクラスター、サービス、タスクをシステムや機能などに応じて分けて構築する必要があります。
    また、コンテナ間の通信についてはサービス検出、内部ロードバランサー、サービスメッシュの利用などユースケースに合わせた検討を行うことで、必要な通信のみが可能な構成とすることが可能です。
    その他、Amazon EC2などと同様にSecurity GroupやNetwork ACLを用いて通信の制御を行う必要があります。
    https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/bestpracticesguide/networking-connecting-services.html
  • ワークロードの機微性レベルの混合
    本リスクについてはAmazon EKSやAmazon ECSを利用することで対応できる範囲となりますが、タスク、サービスを機能や用途によって分けるといった対応が必要になります。
  • オーケストレータノードの信頼
    本リスクについてもAWS EKSやAWS ECSを利用する場合には利用者側で対策する必要はありません。AWSにて対応可能な範囲となります。

④コンテナにおけるリスク

  • ランタイムソフトウェア内の脆弱性
    本リスクについてはAWS Fargate（Amazon EKS、Amazon ECS）を利用することで利用者側での対策は必要ありません。AWSにて対応可能な範囲となります。
  • コンテナからの 無制限のネットワークアクセス
    Amazon EC2などと同様にSecurity GroupやNetwork ACLを用いてVPC内もしくはVPC外との通信の制御を行う必要があります。
  • セキュアでないコンテナランタイムの設定
    本リスクについてもAWS Fargate（AWS EKS、AWS ECS）を利用することで利用者側での対策は必要ありません。AWSにて対応可能な範囲となります。
  • アプリの脆弱性
    本リスクについてはセキュアコーディングなどセキュリティを考慮したアプリケーションの作りにする必要もありますが、マルウェアなどを含めた侵害を検知するためにはコンテナセキュリティに対応した3rd Party製品の導入を検討する必要があります。
  • 未承認コンテナ
    本リスクについてはIAMユーザやロールの権限を正しく制御しAmazon ECSのタスク、Amazon EKSのpodをデプロイする権限を管理することが必要です。
    また、AWS CodePipeline等を用いたデプロイのワークフロー（CI/CDパイプライン）や、管理者に承認されたコンテナイメージのみが本番環境にデプロイできるような環境を整備することが望ましいです。

⑤ホストOSにおけるリスク

  • 大きなアタックサーフェス
  • 共有カーネル
  • ホスト OSコンポーネントの脆弱性
  • 不適切なユーザアクセス権
  • ホスト OSファイルシステムの改ざん

ホストOSのリスク対策についてはAWS Fargateを利用することで利用者側での対策は必要ありません。AWSにて対応可能な範囲となります。なお、ECS/EKSを利用する場合でもホストをFargateではなくEC2上で利用する場合や、Amazon ECS Anywhere（外部環境）を利用する場合には利用者側でホストOSに対する各リスクへの対策が必要となってきます。

まとめ

本記事ではNIST SP800-190の内容をベースに「コンテナにおけるコアコンポーネント」「コアコンポーネントにおけるセキュリティリスク」「AWS Fargate環境におけるコアコンポーネントのセキュリティ対策」について記載させていただきました。大部分はAWSのサービスの利用や設計・設定によって対応できますが、マルウェア対策など一部のセキュリティリスクについては3rd Party製品の導入も検討した方が良いと考えています。
TISではサーバ環境・サーバレス環境問わず様々なシステム/サービスの構想・要件定義・設計・構築・運用に携わっております。AWSをはじめとしたクラウドやオンプレ環境にシステム・サービスの実現に際してお困りのお客様がおられましたら、TISまでご相談ください。

著：TIS株式会社　IT基盤技術事業部　IT基盤エンジニアリング第4部　布川　将来人

PAGE TOP

サービスに関する資料をご希望の方は、フォームに必要事項を入力いただき、ご送信ください。

資料を請求する

お問い合わせ
各種お問い合わせページ
お問い合わせフォーム
サービスに関するお問い合わせ
お電話
0800-600-9810
携帯電話
050-5816-9805
受付時間 9:00～12:00 13:00～17:00（土・日・祝日を除く）

更新日時：2024年4月18日 15時6分