S3の情報漏洩からデータを守るには？ CloudFormationで作るS3標準テンプレートのご紹介 2023/11/15 株式会社セゾン情報システムズ 坪井 千春 1 Security-JAWS #31

自己紹介 名前： 坪井 千春 所属： 株式会社セゾン情報システムズ 仕事： アーキテクト、CCoE 好きなAWSサービス： Amazon ECS(Amazon Elastic Container Service) 経歴： ・SIerとしてJAVAメインのアプリ開発を19年 ・直近6年程度AWSを利用 ・2022年4月からアプリを離れてAWSエンジニアとして活動 2

アジェンダ 3 1.S3からの情報漏洩の事例 2.リソースベースポリシーの重要性 3.S3標準テンプレートのご紹介 4.まとめ

１．情報漏洩の事例 4

情報漏洩の事例 5 意図せず公開状態となる事例が絶えない ◆2022年7月 海外 最大3TBの個人情報 空港の従業員が所有する機密データが流出。約3TBのデータを含むAWS S3バ ケットが認証不要な公開状態となっていた。2018年までさかのぼる空港従業員 の記録、IDカードの写真、氏名、写真、職業、国民ID番号などの個人を特定で きる情報（PII）で構成されていた。 ◆2022年6月 国内 622人の個人情報 旧サーバから AWSサーバへのデータ移行時に、AWS S3バケットにお客様情報を バックアップとして保管していたが、S3バケットを公開設定としていたために 第三者が閲覧可能な状態となっていた

最近の統計 6 ミスコンフィギュレーションに起因した事故が多い Googleによると2023年第1四半期におけるGoogle Cloudへの侵害要因のうち、 ミスコンフィギュレーションは19%を占めており、パスワード強度に次いで2位。 ミスコンフィギュレーションは、他の侵害要因とも関連しており、例えば、 誤って公開アクセスを許可したファイアウォールなどがある。 Google Cybersecurity Action Team (GCAT)「 August 2023 Threat Horizons Repor 」 https://services.google.com/fh/files/blogs/gcat_threathorizons_full_jul2023.pdf

最近の統計 7 ミスコンフィギュレーションに起因した事故が多い OWASP TOP10 2023年6月に発表された「OWASP API セキュリティリスクトップ 10 – 2023」に おいて「セキュリティの設定不備」が8位 1.オブジェクトレベルの認可の不備 2.認証の不備 3.オブジェクトプロパティレベルの認可不備 4.無制限なリソース消費 5.機能レベルの認可の不備 6.機密性の高いビジネスフローへの無制限アクセス 7.サーバーサイドリクエストフォージェリ 8.セキュリティの設定不備 9.不適切な資産管理 10.安全でないAPIの使用 https://owasp.org/API-Security/editions/2023/en/0x11-t10/

なぜ？ 8 S3は設定誤りがおきやすいと思われる • S3は簡単に利用でき、多機能であるがゆえに設定ミスが起こりやすい • 静的ウェブサイトホスティング • パブリックアクセスの許可 • デフォルトではバケットポリシーが無い • 2023年4月から全ての作成方法でS3パブリックアクセスブロック有効、ACL無効を デフォルト化 • セキュリティ対策 • AWS Config • Amazon Guard Duty • Amazon Macie など多層防御として方法は多々あるが、今回は・・

２．リソースベースポリシーの重要性 9

リソースベースポリシーとは 10 IAMポリシーとして設定できる対象のひとつ アイデンティティベースポリシー IAMユーザー、IAMグループ、IAMロールにアタッチされ、そのエンティティが行うことができるア クションとアクセスできるリソースを制御する。例えば、特定のIAMユーザーがS3バケットに対し てどのような操作を行うことができるかを定義することが可能。 リソースベースポリシー リソース自体にアタッチされ、そのリソースに対するアクセスを制御する。リソースベースポリ シーは、特定のリソースに対してどのIAMエンティティがどのようなアクションを実行できるかを 指定する。S3バケットのリソースベースポリシーは「バケットポリシー」と呼ばれる。 ※他もあるが今回は割愛 この人が何をできるか リソースへのアクセス条件

リソースベースポリシーでできること 11 対象のリソースに対するアクセス制御が可能 特定のリソースへのアクセス制御 特定のIAMエンティティ（ユーザー、グループ、ロール）がそのリソースに対して どのようなアクションを実行できるかを定義することが可能。 クロスアカウントアクセスの許可 他のAWSアカウントのIAMエンティティに対してリソースへのアクセスを許可する ことが可能。複数のAWSアカウント間でリソースを共有する必要がある場合に特に 有用。 条件付きアクセス制御 特定の条件が満たされた場合にのみアクセスを許可するようなルールを定義する ことが可能。例えば、接続元IPアドレス、アクセス可能時間帯など。

データ境界の確立 12 リソースベースポリシーはアクセスコントロールにおける重要機能 https://aws.amazon.com/jp/identity/data-perimeters-blog-post-series/ • VPCEのリソースベースポリシーで 他アカウントへのアクセスを明示 拒否によりマルウェアが侵入して も情報の持ち出し不可 （エンドポイントポリシー） • S3のリソースベースポリシーによ り、他ネットワークからのアクセ ス不可 （バケットポリシー）

３．S3標準テンプレートのご紹介 13

テンプレートの概要 14 最低限のセキュリティを全システムに適用するテンプレート CloudFormationでS3のリソースを作成する際に使用するテンプレートで、 セキュアなS3を構築するためのベストプラクティスを反映したもの CloudFormationにより標準化、展開が容易 システムの開発開始時の雛型として利用 →セキュリティのベースラインを担保 主な機能 ①アクセスコントロール ②暗号化の強制 ③バージョニングやStorageLensの容易な設定

主な機能①：アクセスコントロール 15 リソースベースポリシーによる明確なアクセス制御 ⚫パブリックアクセスブロック設定 ⚫指定により、VPC Endpoint経由限定 ⚫アクセス可能なIAMロールを限定 暗黙拒否を利用しない明示的アクセスコントロール ・必要最低限のアクセスを明示的に許可 ・それ以外のアクセスを明示的に拒否 ↓ 指定が無ければ「AdministratorAccess」ポリシーが 付与されたロールも拒否 許可 拒否 指定なし 許可 許可 拒否 許可 拒否 拒否 拒否 拒否 指定 なし 許可 拒否 拒否 （暗黙的拒否） アイデンティティベースポリシー リソースベースポリシー 利用しない

アクセス可能なIAMロールを限定 最小権限の原則に従って権限を分割 Admin • バケット自体に対する管理権限を有する • バケット内のオブジェクトは書き込みできない Writable • バケット内のオブジェクトに対する管理権限を有する • バケット自体の設定（バケットポリシー等）は書き込みできない ReadOnly • オブジェクトの参照専用 • バケット自体の設定やオブジェクトの書き込みはできない 16 バケット自体 オブジェクト Admin Read/Write × Writable × Read/Write ReadOnly × Read アプリ（EC2等）は「Writable」とすることで、万が一マルウェアに乗っ取ら れた場合もバケットポリシーの変更はできず、被害の拡大を防ぐことができる

IAMロールによるアクション制限 17 各ロール権限範囲のアクションを定義 権限一覧（一部を抜粋） • S3のアクションは130種類 • リソースベースポリシーで記載できないア クション49件を除く81件に対し、各ロール に権限を定義 ・ ・ ×81件 No アクション Admin Writable ReadOnly 1 AbortMultipartUpload ○ 2 BypassGovernanceRetention ○ 3 DeleteBucket ○ 4 DeleteBucketPolicy ○ 5 DeleteBucketWebsite ○ 6 DeleteObject ○ 7 DeleteObjectTagging ○ 8 DeleteObjectVersion ○ 9 DeleteObjectVersionTagging ○ 10 GetAccelerateConfiguration ○ ○ ○ https://docs.aws.amazon.com/ja_jp/service-authorization/latest/reference/list_amazons3.html

バケットポリシー概要 Not〇〇により想定外アクセスを明示拒否 1. 想定外アクセスを全拒否 • Admin,Writable,Readonlyロール以外(StringNotEquals)の全 てのプリンシパルに対して全てのアクションを拒否 2. Adminロールに対するポリシー設定 • 権限を有するアクションを許可 • 上記以外(NotAction)を拒否 3. Writableに対するポリシー設定 • 権限を有するアクションを許可 • 上記以外(NotAction)を拒否 4. Readonlyに対するポリシー設定 • 権限を有するアクションを許可 • 上記以外(NotAction)を拒否 18

コード例：想定外アクセスを全拒否 Admin,Writable,Readonlyロール以外(StringNotEquals)の 全てのプリンシパルに対して全てのアクションを拒否 19

コード例：Adminロールに対するポリシー設定 • 権限を有する49件のアクションを許可 • 上記以外(NotAction)を拒否 20 拒否 許可

コード例：Writableロールに対するポリシー設定 • 権限を有する54件のアクションを許可 • 上記以外(NotAction)を拒否 21 拒否 許可

主な機能②：暗号化の強制 22 全ての暗号化を強制しKMSの設定もセットで行う ⚫暗号化通信の強制 HTTPSトランスポートでのみアクセス可能 ⚫強固な暗号化スイートの強制 TLSv1.2以上でのみアクセス可能 ⚫サーバーサイド暗号化の強制 AWS KMSキーを使用したサーバーサイド暗号化を適用 暗号キーは下記を選択可能 SSE-KMS(AWS Managed Key) SSE-KMS(Customer Managed Key) パラメータ有無によりKMSキーもセットで作成 KMSのリソースベースポリシー（51アクション）もS3の権限と同様に定義

主な機能③：バージョニング／StorageLens 23 バージョニングやStorageLensなどを容易に設定 ⚫バージョニング及びバージョンデータのライフサイクル設定可能 ⚫不完全なマルチパートアップロードの削除がデフォルトで設定済み ⚫StorageLens（高度なメトリクス）の作成可能 標準：ストレージサイズ、オブジェクト数、等 高度：リクエスト数、エラー数、等

S3標準テンプレートの課題 24 開発環境での利用しやすさ ⚫オブジェクトの一覧表示はAdminにも付与してよいのではないか ⚫Readonlyロールは不要なケースもあるので必須ではなくオプション項目に 使い初めの学習コスト ⚫S3標準テンプレートが900行 →コメントの充実化 ⚫パラメータが11項目 →必須項目を減らす 利用範囲 ⚫用途によっては標準テンプレートを採用できない制約がある。例えばALBのア クセスログの場合はロールを指定できず、SSE-KMSも利用できない →用途専用のテンプレートを用いる

４．まとめ 25 S3からの情報漏洩は深刻なリスク リソースベースポリシーを使って適切にアクセスコント ロールを行うことが重要 CloudFormationで作るS3の標準テンプレートはセキュア なS3を標準化するための便利なツール