re:Inforce 2019に行ってきた (FND311 – Don’t be a haven for attackers: Mitigate misconfigurations with AWS Service Catalog and Control Tower)

こんにちは、ひろかずです。
AWSが開催する、初のセキュリティ特化型カンファレンスre:Inforce2019に行ってきたので、一筆書きます。

ひろかずは、英語のヒアリングが非常に苦手なのですが、パッションだけで参加してきました。
初めて使う様々なツールを駆使しての執筆になりますので、いろいろご容赦ください。

tl;dr的な何か

  • 設定ミスや一貫性のない展開は、攻撃者が脆弱性を見つけ機会を提供している。
  • 構成の誤りやワークロード導入のばらつきを軽減するための階層型の詳細な防御メカニズムとして、Sarvice Catalogをどのように利用しているかを紹介する
  • また、Control Towerがどのようにしてポリシーの執行のためのガードレールを提供するかに焦点を当てる

サービスの概要や背景

Service Catalog

  • 長期的に組織が集中管理できる方法を検討する
  • サービスとしてローンチできる範囲は、AWSサービスに限らず、3層のアプリケーションをデプロイしたり、ガードレールと非常に成熟したタギングを備えたアプリケーションをコンテナ化したりすることができる。
  • セキュリティの第二の層は、エンドユーザーがコンソールにアクセスできない事実によってもたらされる
  • ポートフォリオに追加すると、ユーザーはコンソールにアクセスできなくなるなどの使い方

Control Tower

  • Control Towerは、自動化されたマルチアカウント環境をセットアップする方法である
  • 自動Landing Zoneの作成は、Control Towerが60分から90分以内に行い、自動Landing Zoneに組み込まれる
  • アカウントは、AWS SSOで収容する
  • ガードレールの設定(ポリシーの強制)
  • ダッシュボードでアカウントのワークロードを継続的に可視化
  • これは、1,000社以上の顧客との協力の下、AWSが1年半かけて開発してきたベストプラクティス

重要な原則

  • Control Towerで作られたアカウントは、Control Towerで作られたログ集約環境に集約された監査機能が提供される
  • これらは、アカウントファクトリを通じて導入される

ゲストスピーカー:アンディさん

  • WBGという会社
  • チャレンジとして、伝統的なウォーターフォール型の開発ではなく、すばやい変更と実装、デリバリが必要だった
  • セキュリティコントロールは、ミスコンフィグレーションが発生する可能性があった
  • 大量のオンプレミスアプリケーションをクラウドに展開する必要があった
  • 複数のAWSアカウントでビジネスを展開する上で、セキュリティチームはポリシーを強制する必要があった

Security as Codeの道のり

  • 複数のCFnテンプレートをサービスカタログで展開
  • VPCにはセキュリティスタックが展開される
  • DevSecOpes CI/CD Pipeline
  • アプリケーションコードの変更ステップにhookしてセキュリティテストやペネトレーションテストをかけている
  • DepOpesサイクルのCodeで静的解析を行い、デプロイの時点で動的解析を行う
  • ビルド時にソフトウェアやライブラリの脆弱性や依存関係をチェックしている

実装のPoC

  • 開発者はアプリケーションを作って、アプリケーションパターンをCFnのスタックにする
  • DevOpsの流れでテストを回して、サービスカタログに登録する
  • ビジネスアプリケーションチームは、AWS環境にサービスカタログに登録されたCFnを実行する

デモ

Service Catalog

  • プロダクション環境を構成するCloudFormationテンプレートをCodePipeLineを使ってテストする。
  • パイプラインの途中でセキュリティスキャンを行う
  • 事前定義したSGの設定に準拠していない不備とか検出してる
  • 不備の箇所は、CodeCommitで修正して、PR、マージしてから、再度パイプラインを回す

Control Tower

  • Control Towerから作成したアカウントは、全てControl Towerのダッシュボードに掲載される
  • Control Towerには、様々なツールが並んでいる
  • ポリシー違反をしているアカウントとそのリソースが集中的に把握できる
  • Control Towerは、OrganizationのOUを2つ(CoreとCustom)を作るが、OUは増やすことができる
  • 予防的な制御としてSCPが内部で利用される
  • ガードレール設定として、ずらりと並んでる
  • インターネットからのSSHやRDPを許可しないという設定もある
  • 発見的統制として、自動修正も行えるし、手動修正プロセスを回すこともできる
  • また、ログファイルは、通常の権限では編集できない

質疑応答

Control Towerのロードマップに質問が集中しました。

Control Towerは、CloudFormation(以下CFn)をサポートできますか?

  • プロダクト環境にControl Towerを導入するには、CFnを使用するか、CFnを使用してポートフォリオとService Catalogを構築し、それを総合的なコントロールタワーに導入することです。

既存環境にControl Towerを導入できますか?

既存環境をControl Towerの管理下に移動することはできないとのことです。

既存環境をControl Towerを導入するロードマップを教えてください

確認するとのことです。

感想的な何か

  • 日本ではService Catalogの利用はまだまだだと思いますが、プロダクションのスピーディーな展開には欠かせない存在になりそうです。
  • Control Towerの東京リージョン利用開始までに、既存環境のControl Towerへの導入が機能追加されているといいですね!

現場からは以上です。
お疲れ様でした。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です