コンテナのセキュリティ対策とAWS運用のポイント【CNDO2021登壇レポート】

本セッションのテーマ：クラウド×コンテナのセキュリティ対策

本セッションについてですが、クラウド×コンテナでリリースするまでに、セキュリティ観点で「どこをがんばるべきなのか」「どこで楽をすべきなのか」についてお話しします。
クラウドやコンテナについての技術の詳細については割愛します。

GMO-PGではクラウドサービスでAWSを採用しているため、若干話がAWSに寄ってしまうかもしれませんが、なるべく一般的な用語で解説しますのでご容赦ください。

クラウド×コンテナのセキュリティで押さえる3つのポイント

クラウド×コンテナセキュリティのポイントとして3つ解説いたします。

まず、責任範囲を減らすという点に関しては、責任をクラウドや各種基準内での責任、コンテナ利用における責任に分類します。

1．責任共有モデルとマネージドサービスで管理範囲を整理する

クラウドの責任共有モデルとセキュリティ基準

クラウドや各種基準内での責任についてです。

社内のセキュリティ担当や、監査機関はクラウド技術を追っているわけではないので、責任共有モデルや、各種セキュリティ基準の責任分界点はもちろんベースとなるクラウド知識が十分ではない可能性があります。
これらの前提が共有できていないと意見の食い違いが起きやすくなったり、後で大きな戻り作業が発生する原因になります。
そのため、図のようにベースとなるクラウド知識から順番に、最低限の説明や読み合わせをしていくことをお勧めします。
そのうえで譲れない部分は設計視点でクラウドベンダーに確認を行います。ただ、ベンダー側も具体的な値や設定方法まで答えられないこともありますので、十分に考慮したうえで、テストを行って、リスクアセスメントを行って、クラウド利用の可否を判断してください。

コンテナ固有のリスクとマネージドサービスの活用

次にコンテナ利用における責任です。
コンテナを採用するにあたって参考にすべき基準はいくつかありますが、ここでは代表的なNISTという基準を参照します。
それによると、コンテナ利用においては、１から５のようなリスク、つまりセキュリティのポイントが出てきます。これらはすべて自社で構築したインフラで対応しようとするとセキュリティ工数の増大につながるため、可能であれば、各種セキュリティ基準を満たしたマネージドサービスの利用をお勧めします。
弊社の場合ですと、①イメージリスクや、④コンテナリスク、稼働するコンテナ以外の部分をPCI DSSという基準を満たしたマネージドサービスで構成し、責任範囲を狭めています。

2．クラウド導入に合わせて統制とセキュリティ対策を見直す

クラウド×コンテナセキュリティのポイント2つ目、「インフラの変化に対応する」についてです。
クラウド×コンテナというインフラを採用するにあたって、既存の統制やセキュリティ対策についても連携する必要があります。

ID・権限管理、操作証跡、本番環境アクセス制御

まず、統制に関しては、
① APIアクセスを前提とした、証跡取得または保管
② 社内申請システムへのID・権限追加と権限付与の仕組みの導入
③ セキュリティ要件や共通のインフラの制限を考慮した本番環境アクセス制御
の3点に対応していく必要があります。

これらは、会社ごとの仕組みの差異が大きく、弊社も依然として対応している状況ではありますが、反省も含めて簡単に対応ポイントを共有します。

まず、全ての前提として、ID管理の整理をきちんと行いましょう。AWSであれば、アカウント、ユーザー、グループ、ロール、ポリシーがそれに該当します。そのうえでクラウドを利用するプロジェクトや、必要な環境の種類、クラウドを利用する人の役割の分類等を考慮しID、権限の作成基準を定めます。
そのうえで、事前に定義された手順やコードを用いて、IDや権限を作成しましょう。

① については、オンプレミスの各種サーバーログインを前提とした証跡取得から、APIアクセスを前提としたクラウド版の証跡取得への変更をします。ただ、それぞれのクラウドサービスの監査系のマネージャーサービスを用いていれば、証跡の保護や保存、またその後の分析などはそれほど難しいことではないと思います。
② については、現状利用している申請システムにおいて、前述のような整理された方法で、IDや権限を追加したうえで、申請・承認のフローを回すことができるか、承認者を含めて事前に運用を確認すべきでしょう。また、権限付与を自動化する場合は、クラウドへのインターネット経由のAPIアクセスが前提のため、新たな仕組みを考える必要があるでしょう
③ については、特に慎重になる必要があります。というのも、一般的に本番環境へのアクセスについてはアクセス元端末や端末が存在する部屋への入室制限、アクセス元ネットワークなど、多くの物理的かつ統制上変更が難しい制限がある共通インフラの利用を前提とした場合が多いからです。弊社では、アカウントを環境、サービスごとに分け、個別のIDを用意し、本番用のIDのみ接続元をわけることで本番環境アクセスの制御を実現しています。

クラウド環境に合わせたセキュリティ対策

次にセキュリティ対策の変更です。
一般的には脆弱性スキャンやWebアプリケーション保護などレイヤーごとに様々な対策があります。弊社の場合、それらはセキュリティ基準や社内外の要件を満たしたマネージドサービスを利用しました。プラスαを工夫したところとして一例を紹介します。

読み取り専用コンテナによる改ざん対策

まず、改ざん検知対策としてリードオンリーコンテイナーとすることで 、そもそも改ざんできないような仕組みを導入しています。AWSの場合だと、コンテナ定義に以下のような設定を追加することでリードオンリーコンテナの構築は可能です。
ただ、コンテナ上で稼働するアプリケーションに影響を与えますので、十分な検証を行ってから導入してください。

コンテナイメージの脆弱性・ウイルススキャン

コンテナイメージに対しては、脆弱性スキャンだけでなくウイルススキャンも実行しています。方法としては、OSSのスキャンツールをインストールしたサーバーをスキャンのために構築し、各種テスト後にスキャンを実行しています。
その後セキュリティ担当のチェックを受けたイメージのみ本番環境にデプロイできるような状態にしています。

スキャンのたびに構築するというのは、スキャンツールの特性を生かすために重要な過程です。そもそもスキャンツールは最新のセキュリティー情報を複数の外部サイトから取得し内部のデータベースに格納します。そのデータをもとにイメージから構築されるコンテナ内のOSパッケージや依存ライブラリなどのソフトウェアを一つずつ調査していくことで常に最新の情報でスキャンすることができます。

FQDNベースのアウトバウンド通信制限

プラスαのセキュリティ対策の最後に、コンテナとは直接関係ありませんが、アウトバウンド通信のFQDNベースフィルタリングについても紹介します。
弊社ではアプリケーションコンテナから、特定の外部サイトのみにしか接続できないように制限するという要件がありました。しかし、AWS東京リージョンのマネージドサービスでは、現時点ではIP、ポート、プロトコルによる制限のみ可能で、FQDNフィルタリングを実現することができません。
そのため、弊社では図のようにプロキシのコンテナを内部ロードバランサーで冗長化する形で構築し、外部サイト接続時に必ずプロキシのホワイトリストに合致するか確認する仕組みにしています。

3．マネージドサービスを活用した継続的なセキュリティ管理

最後に、マネージドサービスによるセキュリティ強化です。
ポイントは2つで、1つはセキュリティ状況全体の把握や脅威への事前対応。APIベース変更検知です。

セキュリティ基準への準拠状況の確認と脅威対応

1つ目のセキュリティ状況は全体の把握や脅威への事前対応について、弊社では図のように対応しています。CISベンチマークというクラウドベンダーに依存しないセキュリティ基準や弊社が準拠すべきPCI DSSというセキュリティ―ルールを作成一覧化し、アカウント内のすべてのリソースを定期的にチェックしています。
ルール違反のリソースが発生した場合は、イベントベースで通知がくるような仕組みも合わせて構築しています。

このようにセキュリティ状況全体の把握や、違反をイベントベースで検知できるようなマネージドサービスは、有名どころのクラウドサービスであればどこでも利用できると思います。
ただし、これらの仕組みはしっかりと運用を続けていくことが前提となります。
弊社では設定するセキュリティ―ルールひとつひとつ の有効か無効かの判断、アカウント毎もしくはリソース毎の対応方法の変更、他のセキュリティーサービスとの連携などを定期的に見直しています。

API操作ログに基づく想定外の変更検知

2つ目のAPIベースの変更検知について
弊社ではアカウント内のインフラ操作した証跡ログや、アカウント内のイベントをフィルタリングして、想定外のIDからの本番環境アクセスや、環境内のリソース変更を検知できるようにしています。従来のインフラではファイルベースの変更を検知でしたが、クラウドは原則APIベースで変更されるので、このような仕組みが必要でした。
ここでのポイントは、「どのIDが一般的にはどのユーザーになるか」だと思いますが、「どのリソースを変更した時に検知したいのか」、を明確にすることです。
クラウドサービスでは、もろもろ機能がマネージド化されているため、あるサービスが別のサービスを変更することは多いと思います。例えば、Scaling用のサービスが、CPUの上昇を検知して、コンテナ定義サービスの設定をAPI経由で変更し、コンテナを追加するようなことです。
これらすべての変更を検知してしまうと、膨大な通知に追われ実質通知が無視されてしまうような状況になってしまう可能性があります。
そのため検知する基準については十分精査した形での導入をお勧めします。

まとめ

まとめです。クラウド×コンテナのセキュリティのポイントは、
技術知識等の前提の共有やアセスメントにより責任範囲を減らすこと、
既存の運用で変更する必要がある箇所を事前に把握し準備しておくこと、
その上で、既存の仕組みをクラウド×コンテナに採用させるマネージドサービスの活用や、運用を行うことでクラウドならではのセキュリティリスクに備え、堅牢性を強化すること
の3つでした。

少しでも皆様のインフラ構築の参考になれば幸いです。

▶ 関連採用情報：エンジニア・デザイナーの求人一覧を見る

採用情報はこちら

エンジニアイベント書き起こし記事一覧はこちら

FAQ