More Related Content
Similar to Cloudnativedays2021 Container security (20)
Cloudnativedays2021 Container security
- 1. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved. 1
インフラ目線で見た、
初めてコンテナでサービスリリースするときの
セキュリティポイント
システム本部 山崎 牧彦
- 2. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved. 2
アジェンダ
• 自己紹介
• 本セッションについて
• クラウド×コンテナセキュリ
ティのポイント
• まとめ
- 3. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved.
自己紹介
3
仕事
・インフラ3年目
（ほぼクラウドだけ）
・未経験で金融業界へ
・AWSサービスインフラ構築、
AWS運用業務全般
プライベート
・旅行、サッカー観戦
- 4. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved.
本セッションについて
4
話すこと
クラウド×コンテナでリリースするまでに、セキュリティ観点で
・どこをがんばるべきなのか
・どこで楽をすべきなのか
話さないこと
クラウドやコンテナについての技術詳細
- 5. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved.
クラウド×コンテナ セキュリティのポイント
5
・責任範囲を減らす
・インフラの変化に対応する
・マネージドサービスによるセキュリティ強化
- 6. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved.
責任範囲を減らす
6
・クラウドや各種基準内での責任
・コンテナ利用における責任
- 7. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved.
責任範囲を減らす
7
・クラウドや各種基準内での責任
クラウド基本知識
責任共有モデル
セキュリティ基準のクラウド責任分解点
個別サービスのセキュリティ準拠
順を追った共有が大切
- 8. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved.
責任範囲を減らす
8
①イメージリスク
②レジストリリスク
③オーケストレーターリスク
④コンテナリスク
⑤ホストOSリスク
できるだけセキュリティ基準を満たしたマネージドサービス
参照：https://doi.org/10.6028/NIST.SP.800-190
・コンテナ利用における責任
- 9. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved.
インフラの変化に対応する
9
・統制の変更
・セキュリティ対策方法の変更
- 10. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved.
インフラの変化に対応する
10
・統制の変更
整理されたID/権限の管理をベースに、
①APIアクセスを前提とした証跡取得/保管
②社内申請システムへのID/権限追加と権限付与の仕組導入
③セキュリティ要件や共通インフラの制限を考慮した
本番環境アクセス制御
- 11. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved.
インフラの変化に対応する
11
・セキュリティ対策方法の変更
マネージドサービス＋α
- 12. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved.
インフラの変化に対応する
12
改ざん検知：
readonlyコンテナにすることで、そもそも改ざん不可にする
参照： https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html
AWSの場合
- 13. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved.
インフラの変化に対応する
13
ウィルス対策：コンテナイメージスキャン
- 14. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved.
インフラの変化に対応する
14
アウトバウンド通信制限：FQDNベースフィルタリング
- 15. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved.
マネージドサービスによるセキュリティ強化
15
・セキュリティ状況全体の把握や脅威への事前対応
・APIベース変更検知
- 16. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved.
マネージドサービスによるセキュリティ強化
16
セキュリティ状況全体の把握や脅威対応の簡易化
- 17. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved.
マネージドサービスによるセキュリティ強化
17
APIベース変更検知
- 18. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved.
まとめ
18
・責任範囲を減らす
→順を追った前提の共有やアセスメントを行う
・インフラの変化に対応する
→自社の既存の仕組をクラウド×コンテナに対応させる
・マネージドサービスによるセキュリティ強化
→クラウドの特性を活かした仕組を構築し、確実に運用する
- 19. Copyright (C) 1995 GMO Payment Gateway, Inc. All Rights Reserved. 19
募集職種
募集職種
ア プ リ ケ ー シ ョ ン エ ン ジ ニ ア ・ イ ン フ ラ エ ン ジ ニ ア ・ テ ク ニ カ ル サ ポ ー ト エ ン ジ ニ ア
セ キ ュ リ テ ィ エ ン ジ ニ ア ・ デ ー タ ベ ー ス エ ン ジ ニ ア ・ 社 内 情 報 シ ス テ ム
GMO-PGのシステムエンジニアの4つの魅力
1. マイシステム・マイサービスに携わる 2. フルフェーズ・フルスタックをすべて内製開発
3. ミッション・クリティカルな領域へのチャレンジ 4. 守り続けている大切な企業文化
※GMO-PG連結企業集団 2020年1月から2020年12月の数値
https://recruit.gmo-pg.com/
採用特設サイトはこちら
Editor's Notes
- インフラ目線で見た初めてのコンテナサービスをリリースするときのセキュリティポイントと題しまして,GMOペイメントゲートウェイの山崎から発表させていただきます 。よろしくお願いいたします。
- アジェンダは次の通りです。
- 少し自己紹介させていただきます。 山崎まきひこと申しまして、 2年半ほど前に弊社に入社しました。インフラはその時から始めています。
未経験で金融業界に入りまして、今は AWSのインフラ構築や運用全般などAWSなら何でもやっている ようなは仕事をしています 。趣味は 旅行 だったり サッカーを見るのが好きです 。
- 本セッションについてです。本セッションでは、 cloud＊コンテナで本番リリースするまでに、セキュリティという観点でどこをがんばるべきなのか、どこで楽をすべきなのかをざっくり解説したいと思っています。
弊社はクラウドサービスとしてAWSを採用しているため、若干話しがAWSによってしまうかもしれませんが、なるべく一般的な用語で話すつもりです。ご容赦ください。
また、クラウドサービスやコンテナついて基本的な知識を前提としており、詳細な用語・技術の解説はいたしません。
- それでは本題に入って行きます 。クラウド×コンテナのセキュリティポイントとして 以下3つについて解説させていただきます。
1つ目が責任範囲を減らす、 2つ目がインフラの変化に対応する、 3つ目が マネージドサービスによるセキュリティーの 強化 になります。
- まず責任範囲を減らすという点では、責任をクラウドや各種セキュリティ基準内の責任 、コンテナ利用における責任というふうに分類します。
- まず、クラウドや各種基準内での責任範囲についてです。
社内のセキュリティ担当や 監査機関などはクラウド技術を追っているわけではないので、 責任共有モデルや各種セキュリティ基準の責任分解点はもちろん、ベースとなるクラウド知識が十分でない可能性があります。
これらの 前提が共有できていないと 、意見の食い違いが起き易くなったり、後で大きな戻り作業が発生する原因になったりします。 そのため、図のようにベースとなるクラウドの知識から順番に、最低限の説明や、読み合わせをしていくことをお勧めします。
その上で、譲れない部分は設計時点でクラウドベンダーに確認を行います。
ただ、ベンダー側も具体的な値や設定方法等まで答えられないこともありますし、環境制約でクラウド上でのセキュリティテストができない場合もあります。
その際は、 十分なリスクアセスメントを行って、クラウド利用の可否を判断してください。
- 次にコンテナ利用における責任です。
コンテナを採用するにあたって、参考にすべき基準はいくつかありますが、ここでは代表的なNISTの基準を参照します。
それによるとコンテナ利用においては、①から⑤のような リスク、つまりセキュリティポイントが 出てきます 。
これらすべてを自社構築したインフラで対応しようとすると、セキュリティ対応 工数の増大 に繋がるため、可能であれば、各種セキュリティ基準を満たしたマネージドサービスの利用をお勧めします。
弊社の場合だと ① dockerイメージや ④稼働するコンテナ以外の部分を、pci dssという基準を満たしたマネージドサービスを使って構成し、責任範囲を狭めています。
- クラウド×コンテナ セキュリティのポイント２つめの、インフラの変化に対応する、です。
クラウド×コンテナというインフラを採用するにあたって、 既存の統制やセキュリティ対策についても変更する必要が あります 。
- 統制という意味では、スライドの通り
①APIアクセスを前提とした証跡取得/保管
②社内申請システムへのID/権限追加と権限付与の仕組導入
③セキュリティ要件や共通インフラの制限を考慮した本番環境アクセス制御
という3点において対応していく必要があると思います。
これらは、会社毎の仕組の差異が大きく、また弊社も依然として対応している状況ではありますが、反省も含めて簡単に対応ポイントを共有できればと思います。
まずすべての前提として、管理対象のID、権限を必要最低限にしましょう。AWSであれば、アカウント、ユーザ、グループ、ロール、ポリシーがそれに該当します。
その上で、クラウドを利用するプロジェクト、必要な環境の種類、クラウドを利用する人の役割の分類などを考慮し、ID、権限の作成基準を定めます。
その上で、事前に定義された手順･コードを用いて、IDや権限を作成します。
①については、オンプレミスの各種サーバログインを前提とした証跡取得から、APIアクセスを前提としたクラウド証跡取得への変更します。
ただ、監査系マネージドサービスを用いていれば、証跡の保護や保存、その後の分析はそれほど難しいことではありません。
②については、現状利用している申請システムにおいて、前述のような方法でIDや権限を追加した上で、申請・承認のフローを回すことができるか、承認者含めて運用を事前に確認をするべきでしょう。
また権限付与を自動化する場合は、クラウドへのインターネット経由のAPIアクセスが前提となるため、新たな仕組を考える必要があるでしょう。
③については、特に慎重になる必要があります。
というのも、一般的に本番環境へのアクセスについては、アクセス元端末・端末が存在する部屋への入室制限・アクセス元NWなど、多くの物理的かつ統制上変更が難しい制限がある共通インフラの利用を前提とした場合が多いからです。
弊社では、アカウントを環境＊サービス毎に分け、個別のIDを用意し、本番用のIDのみ接続元を分けることで、本番環境アクセス制御を実現しています。
これらの対策は、自社の状況を十分に把握してから進めましょう。
- 次にセキュリティ対策の変更です。
一般的には、脆弱性スキャンやWebアプリケーション保護などレイヤー毎に様々な対策がありますが、弊社の場合、それらはセキュリティ基準や社内外の要件を満たしたマネージドサービスを利用しました。＋α工夫したところとして一部例を紹介します。
- まず、 改ざん検知対策として、 read only containerとすることで そもそも改ざんできないような仕組みを導入しています。
awsの場合だと コンテナ定義に以下のような設定追加することで、readonlyコンテナの構築が可能です 。
ただ、当然コンテナ上で稼動するアプリケーションに影響がでますので、十分な検証を行ってから導入してください。
- コンテナイメージ対しては 、脆弱性スキャンだけでなくウィルススキャンも実行しています。
方法としては、OSSのスキャンツールをインストールしたサーバーを、スキャンの度に構築し、各種テスト後に、ウィルス スキャンを実行します。
その後、セキュリティ担当のチェックを受けたイメージのみ 本番環境にデプロイできるような仕組みを設けています。
＜スキャンの度に構築する＞のは、スキャンツールの特性を活かすために重要な過程です。
そもそもスキャンツールは、最新のセキュリティ情報を複数の外部サイトから取得し、内部のデータベースに格納します。
その情報を元に、イメージから構築されるコンテナ内のOSパッケージや依存ライブラリ等のソフトウェアを1つずつ調査していくことで、常に最新の情報でスキャンすることができます。
- ＋αのセキュリティ対策の最後に、コンテナとは直接関係ありませんが、アウトバウンド通信のfqdnレベルフィルタリングについても紹介します。弊社では、アプリケーションコンテナから特定の外部サイトのみにしか接続できないように制限する要件がありました。しかし、AWS東京リージョンのマネージドサービスでは、現時点ではIP・port・Protocolによる制限のみ可能で、fqdnレベルフィルタリングをすることができません。そのため、弊社では図のようにproxyのコンテナを内部ロードバランサーで冗長化する形で構築し、外部サイト接続時に必ずproxyのwhitelistに合致しているかが確認されてるような仕組にしています。
- 最後にマネージドサービスによるセキュリティ強化です 。
ポイントは ２つで、1つは、セキュリティ状況全体の把握や脅威への事前対応。２つめは、APIベース変更検知です。
- １つめのセキュリティ状況全体の把握や脅威への事前対応について、弊社では図のように、対応しています。
CISBenchMarkというクラウドベンダーに依存しないセキュリティ標準や、弊社が準拠すべきPCIDSSに基づいたセキュリティルールを作成・一覧化し、アカウント内のすべてのリソースを定期チェックしています。
ルール違反のリソースが発生した場合には、イベントベースで通知してくれるような仕組も合わせて構築しています。
このようなセキュリティ状況全体の把握や、違反をイベントベースで検知できるマネージドサービスは、有名どころのクラウドサービスであればどこも利用できるかと思います。
ただし、これらは仕組をつくるだけでなく、運用をしっかり続けていくことが大切かと思います。
弊社では設定するセキュリティルール1つ1つの有効化/無効化の再判断、アカウント毎もしくはリソース毎の対応方法の変更、他セキュリティサービスとの連携 などを定期的に見直しています。
- 2つめのAPIベース変更検知について、弊社ではアカウント内のインフラを操作した証跡ログや、アカウント内イベントをフィルタリングして、想定外のIDの本番環境アクセスや、環境内のリソース変更を検知できるようにしています。
従来のインフラではファイルベースの変更検知でしたが、クラウドは原則APIベースで変更されるので、このような仕組が必要でした。
ここでのポイントは、どのIDが、一般的にはどのユーザがになるかと思いますが、どのリソースを変更したときに検知したいのかを明確にすることです。
クラウドサービスでは、諸々機能がマネージド化されているため、あるサービスが別のサービスの設定を変更することは多いと思います。
たとえばScaling用のサービスが、CPUの上昇を検知して、コンテナ定義サービスの設定をAPI経由で変更し、コンテナを追加するようなことです。
これらすべての変更を検知してしまうと、膨大な通知に追われ、実質通知が無視されてしまうよう状況なってしまう可能性があります。
そのため、検知する基準については十分精査した形での導入をお勧めします。
- まとめです。
クラウド×コンテナ セキュリティのポイントは、
・技術知識等の前提の共有やアセスメントにより責任範囲を減らすこと
・既存運用で変更する必要のある箇所を 事前に把握し準備しておくこと
・マネージドサービスの活用や確実な運用を行うことで、クラウドならではのセキュリティリスクに備え、堅牢性を強化すること
の３つでした。少しでも皆様のインフラ構築の参考になれば幸いです。
ご清聴ありがとうございました。
