[レポート]Amazon S3 のセキュリティへ Deep Dive -チョークトーク- #SEC319 #reinvent

こんにちは。ちゃだいんです。

この記事は下記チョークトークについてのレポートです。

SEC319-R - Deep dive on security in Amazon S3 -Chalktalk-

そもそもチョークトークって?

チョーク・トーク(Chalk Talk)は、直訳すると黒板にチョークで書きながら会話するという意味で、セッション中に参加者が途中で質問してもOKな、割とカジュアル目な対話形式セッションという感じです。

Speaker

Sam Parmett Software Development Engineer , Amazon Web Services

Felix Davis Principal Product Manager , Amazon Web Services

セッション概要

AWSでは、セキュリティが最優先事項であり、Amazon Simple Storage Service(Amazon S3)は、クラウドで現在利用できる最も高度なデータセキュリティ機能の一部を提供し、セキュリティリスクの軽減に役立ちます。 このチョークトークでは、暗号化、パブリックアクセスのブロックなど、Amazon S3セキュリティ機能を構築および維持するAWSエンジニアリングチームから直接学びます。 フィードバック、質問、専門知識を持ち込み、データを必要とするユーザーとアプリケーションのみがデータを利用できるようにする革新的な方法について話し合います。

※前半ではS3の機能説明であり、ほぼSummitTokyoのセッションと同じだったため、セッション後半の具体例として挙げられたデータレイクのアーキテクチャをご紹介します。

Reference Architecture

最終的には以下の綺麗な構成図が紹介されました。

セッション中はホワイトボードに実際に書きながらの説明でした。

データレイクセキュリティモデルの基本原則

  • ユーザー、取り込み、分析パイプラインの高いカーディナリティのセット
  • 保存時と転送時のデータ保護
  • データの使用許可に関する最小の権限
    • デフォルト拒否
    • 適切なアクセスの許可
  • セキュリティの管理とパターンの監視
    • 構成ドリフト(変更)
    • 異常なアクセス

アーキテクチャの全体について

  • 全部で3つのバケットがある構成
  • 1つ目のProject A bucket(バケットA)はKinesis Firehoseから取り込む想定
  • 2つ目のProject B bucket(バケットB)はベンダーがアップロードする想定
  • 3つ目のLog bucket(バケットC)はログを収集する
  • これらを単独のAWSアカウント内で配置する

1つ目のバケットについて(バケットA)

  • アクセス権限の付与は専用のIAMロールを使用する
  • Abucket/injest のディレクトリを作成
  • IAMポリシーにて以下の内容で作成
    • Effect : Allow
    • Actions : S3:PutObject
    • Resources : バケットAのARN/injest

2つ目のバケットについて(バケットB)

  • アクセス権限の付与は専用のIAMロールを使用する
  • Bbucket/injest のディレクトリを作成
  • IAMポリシーにて以下の内容で作成
    • Effect : Allow
    • Actions : S3:PutObject
    • Resources : バケットBのARN/injest
  • (外部ベンダー(別アカウント)のため、信頼ポリシーにてベンダーAWSアカウントにIAMロールが使用できる状態)

3つ目のバケットについて(バケットC)

  • CroudTtrailの証跡として、当バケットに保存
  • S3 Object Lockでデータを変更不可に
  • バケットポリシーにて以下の内容で作成
    • Effect : Allow
    • Actions : S3:PutObject, GetBucketListなど
    • Resources : バケットCのARN/AL/A, バケットCのARN/AL/B

全体のセキュリティについて

  • 全てのバケットをデフォルト暗号化にて保護
    • うちバケットAおよびBは、 SSE-KMSを使用
  • 全てのバケットをブロックパブリックアクセス(BPA)を有効化

ユーザーについて

  • 各プロジェクトのチーム単位でIAMポリシーを作成し、それをIAMグループで管理する
  • ログバケットにアクセスできるチームを限定し、これもIAMポリシーとIAMグループで管理する

質疑応答の一例

  • Q1 : もしベンダーがAWSアカウントを持っていなかったらどうする?
  • A1 : 別のベストプラクティスがある。IDPフェデレーションを使用する。しかしながら現在AWSは多くのベンダー企業と協力しAWS連携を進めている。
  • Q2 : アカウントレベルで暗号化の機能を有効化することは可能か?
  • A2 : 現段階ではアカウントレベルで有効化することはできない。ただしAWS OrganizationsのSCPで近いコントロールを行うことは可能だ。
  • Q3 : CloudTrailで一部のベンダーのみのログを取得することは可能か?
  • A3 : CloudTrailはバケットレベルのAPIコールを記録しているので、それらを調べる場合にはオブジェクトレベルのログを有効化する必要がある。 等

感想

対話型のセッションであり、実際にS3を作っている開発者とプロダクトマネジャーが応じたというのもあり、活発なディスカッションが行われていました。 また、セキュリティに関するAWSのトレンドワードでもあるガードレールという言葉も頻出していたことが印象的でした。