re:Invent 2024: Amazon S3のセキュリティとアクセス制御ベストプラクティス
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Amazon S3 security and access control best practices (STG304)
この動画では、Amazon S3におけるデータアクセス制御の基本から高度な手法までを包括的に解説しています。S3 Bucketのデフォルトセキュリティ設定や、IAMを活用した基本的なアクセス制御から、S3 Access PointsやS3 Access Grants、AWS Lake Formationなど、大規模なデータレイクでの詳細なアクセス制御を実現するための4つの方法について説明しています。特に、多対多のアクセス制御が必要なケースでは、非構造化データにはS3 Access Grants、構造化データにはLake Formationを使用するなど、ユースケースに応じた最適な選択肢を提示しています。また、2023年初めに導入されたS3の新しいデフォルト設定や、Identity Centerとの統合による監査性の向上など、最新のセキュリティ機能についても詳しく解説しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon S3のセキュリティ：基本から応用まで
ここにいらっしゃる皆さんは、AWSをご利用されているからこそお集まりいただいたわけですが、AWSを使用している以上、遅かれ早かれAmazon Simple Storage Service（S3）にデータを保存することになるでしょう。S3は、クラウドにおいて柔軟でスケーラブル、そして耐久性の高いオブジェクトストレージを提供する基盤的なサービスです。クラウドにデータを置き始めたら、最優先すべきは間違いなくそのデータのセキュリティです。アクセスが必要な関係者だけがアクセスでき、それ以外の人はアクセスできないようにすることが重要です。私たちAWSも、セキュリティを最優先事項として同じように考えています。私はMeg Roseです。この後Becky Weissからもお話があります。私たち二人ともAWSで働いており、これが私たちが日々AWSで考えていることです。
S3は多くの場合、ワークロードの中心的存在です。S3の優れたスケーラビリティ、可用性、耐久性により、ビジネスのData Lakeを構築するのに最適な場所となっています。S3上にビジネスのData Lakeを構築することで、AWSのサービス、パートナーのソリューション、そして自社のアプリケーションによる、より多くのAnalytics、Machine Learning、その他のワークロードが可能になり、データからさらなる価値を引き出すことができます。S3は高可用性のオブジェクトストレージであると同時に、ワークロードを実行するための設定ファイルなど、すべての接続要素を配置するのに非常に便利な場所でもあります。また、おそらくログもS3に保存されているでしょう。これらのユースケースはそれぞれ異なり、異なるセキュリティ目標を持っています。
今日は基本から始めていきます。すでにご存知の方もいらっしゃるでしょう。S3におけるアクセス管理には、ユースケースやデータパターンに応じて、いくつかの大規模なアプローチがあります。これらについて順を追って説明し、それぞれをどのような場合に選択すべきかについてお話ししていきます。今日は皆さんに新しい発見があることを願っています。
S3バケットの基本設定とIAMの効果的な使用
まずはS3 Bucketを作成した時に得られるものから見ていきましょう。S3 BucketはAWSの他のリソース、つまりあなたが所有するものと同様のリソースです。S3 Bucketを作成した瞬間、それは作成したAWSアカウントによって所有され、そのAWSアカウント外のIdentityからのアクセスは一切不可能です。デフォルトでプライベートであり、これは常にそうでした。S3は最近、Bucketを作成する際の設定に3つの変更を加えました。これらは以前は顧客がオプトインするために操作が必要でしたが、現在はBucketを作成するだけで自動的に適用されます。S3 encryption by defaultを導入し、新規および既存のBucketの新しいオブジェクトはすべて、AWS SSE-S3（S3が管理する暗号化）で暗号化されます。他のServer-Side Encryption方式を選択しない限り、これがデフォルトとなります。つまり、データの暗号化に関するコンプライアンス要件は、自動的に満たされることになります。Block Public Accessがすべての新規Bucketでデフォルトでオンになっており、パブリックアクセスの誤設定が不可能になっています。また、S3の古いアクセス方式であるAccess Control Lists（ACLs）は、新規Bucketではデフォルトでオフになっています。
これらの変更は2023年初めに行われたため、それ以降に作成されたものにはすべてこれらの設定が適用されています。2023年以前に作成された古いBucketについても、パブリックアクセスの誤設定を防ぐためにBlock Public Accessをオンにし、IAMのみを使用するようにACLsをデフォルトで無効にすることをお勧めします。これらはBucketレベルの設定で行うことができます。
IAMについて触れましたので、S3でIAMを効果的に使用する方法について説明しましょう。まずは基本的な部分から始めていきます。IAMの基本的な仕組みをまだよく知らない方のために説明しますと、IAMはクラウドスケールで非常に重要です。なぜなら、AWSの他のほとんどすべてのサービスがIAMの上に構築されているからです。IAMはAWS Identity and Access Managementの略です。基本をまだ理解していない方は、IAMのパターンを認識することで学べます。ユーザーはプリンシパルと呼ばれます。IAMにはユーザーが存在しますが、最近のユースケースの多くはRoleを使用します。Roleは一時的な署名認証情報に関連付けられたアイデンティティです。IAMユーザーとRoleは、S3 APIを含むAWS APIへのリクエストに署名するために、これらの認証情報を使用します。これらは認証されたリクエストとなります。ここでは、赤い作業帽子のような小さなアイコンで示された3つのIAM Roleを表示しています。このプレゼンテーションを通じてこの表現を使用します。Roleはプリンシパルであり、Bucketはリソースです。リソースには、実行可能なことと不可能なことを定義するポリシーが付加されています。ここでは、IAM Roleに関連付けられた3つの赤いポリシーと、このアカウントにある緑のポリシーが付いたBucketの例を示しています。IAMにおけるAPIリクエストはアクションと呼ばれます。
最初のポリシーを見てみましょう。このオブジェクトを取得したいので、S3 GetObject APIを使用します。オブジェクトは、ここではexample bucketと呼ばれる私のBucketに存在し、取得したいオブジェクトはpath to objectです。ここで必要なポリシーの種類は、アクセスを許可するAllowポリシーです。必要なアクションはGetアクションで、ここではAPIと一致するS3:GetObjectです。リソースは、取得できるオブジェクトを記述します。ここでは、ワイルドカードのオブジェクトリソースを使用しており、これは私が取得したいこのオブジェクトを含む、example bucket/path/twoプレフィックス内のすべてのオブジェクトを取得できることを意味します。
Bucketのオブジェクトを読み取る際には、多くの場合、それらをリストアップする必要もあります。どのようなオブジェクトを取得しようとしているのか、Bucketに何が存在するのかを知る必要があります。このケースではListObjectsV2 APIを使用します。しかし、アクションやリソースに何を設定すべきかをどうやって知ることができるでしょうか？推測することもできますし、このドキュメントをブックマークすることもできます。これはAmazon S3のIAMドキュメントのページです。Getのように単純ではない場合もあります。ここではListObjectsV2に対応するアクションがS3:ListBucketとなっています。そして、リソースにはこのexample bucketを指定する必要があることがわかります。このドキュメントは、IAMとAmazon S3の使用に慣れる際に非常に役立ちます。
IAMポリシーの実践：複数アカウントでのデータ共有
もう少し複雑な例を見てみましょう。今度は別のAWSサービスが関係するポリシーを見ていきます。この場合、AWS KMS（Key Management Service）を見ていきます。以前、SSE-S3でオブジェクトを自動的に暗号化する方法について説明しましたが、一部のお客様は、自身で所有・管理する鍵でオブジェクトを暗号化するSSE-KMSを選択します。KMS KeysはBucketと同様にリソースです。ここでは、このBucketのオブジェクトを取得できるという同じようなポリシーがありますが、少し異なります。なぜなら、ここのワイルドカードはこのBucket内のすべてのオブジェクトを取得できることを意味するからです。このオブジェクトを読み取れると思う方は手を挙げてください。読み取れないと思う方も手を挙げてください。
ここで何が起きているのか見てみましょう。このポリシーによって、バケット内のオブジェクトを読み取ることができることは既に分かっています。 しかし、このキーで何ができるかについては何も指定していません。以前お話ししたように、キーもリソースの一つなので、できることとできないことを指示するポリシーを持っています。このキーについて何も許可するポリシーがないため、このリクエストは拒否されることになります。では、KMS キーを使用するための権限を追加したポリシーがどのようなものか見てみましょう。 ここにKMSキーのリソースがあり、アクションは復号化を可能にするものです。KMSについて詳しく知りたい場合は、対応するKMSポリシーのドキュメントページがあります。オブジェクトを書き込むには、暗号化アクションが必要です。ここには掘り下げるべき要素がたくさんありますが、今は、オブジェクトを読み取ることができるポリシーができました。
基本的なポリシーの作成方法について説明しましたので、次はデータの共有について話しましょう。 これまでの例は、すべて同じアカウント内のリソースに関するものでした。しかし、この図は実際、最新のAWSベストプラクティス環境ではより一般的なものです。ワークロードを分離するために異なるアカウントを使用することになります。これは運用とセキュリティの境界として有用で、このような構成が多く見られると予想しています。つまり、アカウント末尾33のワークロードが、アカウント末尾66のデータにアクセスする必要がある場合があります。この例では、私のバケットにはすべてのアプリケーションを実行するために必要な設定データが含まれています。ここでも、これまでのスライドで使用してきた、このバケットからオブジェクトを取得できるという同じポリシーがあります。これはアカウント33の私のロールに関連付けられています。
このオブジェクトを読み取ることができると思いますか？できると思う人は手を挙げてください、できないと思う人も手を挙げてください。もう皆さんお分かりだと思いますが、私がこのような質問をする場合、答えは「できない」です。アカウント末尾33で、アカウント末尾66のバケットからオブジェクトを読み取れるというポリシーを持っているからといって、 それができるわけではありません。それは、自分の家の鍵を勝手に複製できるようなものです - それはよくありません。そのため、アカウント66側で何かを指定する必要があります。それをバケットポリシーで行い、 アカウント末尾33が私のバケットからオブジェクトを取得することを許可します。読み取りができることを指定し、バケット側も同意したことで、getが成功するようになりました。
現代のAWS環境では、2つ以上のアカウントを持っている可能性が高く、たくさんのアカウントを持つこともあります。そして、ベストプラクティスに従ってワークロードを分離しているでしょう。
このアクセスを管理するさまざまな方法について、Beckyが説明します。AWS Organizationsを使用している場合の簡単な方法の1つは、Principal org IDを使用して、組織内のすべての呼び出し元がこのバケットを読み取れるようにすることです。Organizationsを使用している場合は、かなり便利な簡略化方法です。
アクセス権の付与について説明しましたが、次はアクセスの拒否とそれを使用したデータペリメーターの設定について説明しましょう。 データへのアクセスが必要な対象を考えると、自身のアカウント、バケットの読み書きを行うパートナーアカウント、Amazon AthenaやBedrockなどのバケットからデータを読み取るAWSサービス、そしてAWS CloudTrailのようにバケットにログを保存するサービスを挙げることができます。 それ以外は想定していません。このサークルをバケットへのアクセスに関する境界として考えると、バケットポリシーを使ってこれをポリシー言語で表現できます。
ここではDenyポリシーを使用します。 このポリシーでは、リクエストが自分の組織からのものでない場合、Amazon S3へのアクセスを拒否します。ここには複数の組織をリストアップすることができます。パートナー組織がデータにアクセスする必要がある場合は、それらを列挙できます。もちろん、AWSを利用している以上、AWSサービスにデータとのやり取りを許可する必要があります。 つまり、呼び出し元が自分の組織からでもなく、AWSサービスからでもない場合、アクセスを拒否します。その上で、許可したいアクセスタイプを追加のステートメントで指定する必要がありますが、これは予期しないアクセスを拒否するための基本的なポリシーとして使用できます。
また、 想定されるネットワークという観点からも考えることができます。VPCやオンプレミスのデータセンターからのアクセスを想定しているでしょう。そこで、別のDenyポリシーを作成します。 このポリシーでは、自分のVPC（複数ある場合はリストアップ可能）からのアクセスではなく、かつ自分のオンプレミスデータセンターからのアクセスでもない場合にアクセスを拒否します。ただし、AWSサービスは自社のネットワークではなくAWSのネットワーク上で動作するため、ネットワーク要件からAWSサービスを除外する、クリーンでスケーラブルな方法が必要です。
すべてのバケットにデータペリメーターが必要だが、何百、何千、あるいは何万ものバケットがある場合、すべてのバケットに同じDenyステートメントが設定されているかを監査するのにエネルギーや人的リソースを費やしたくないでしょう。数週間前に発表したResource Control Policiesがその解決策となります。 AWS Organizationsを使用している場合、Resource Control Policiesを使用してリソースに対する最大許可権限を設定できるようになりました。今回の場合はバケットが対象です。先ほど説明したDenyステートメントをResource Control Policyに変換すれば、既存および今後作成されるすべてのバケットに適用され、監査の必要がなくなります。Organizationsを使用している場合は、ぜひ確認することをお勧めします。これは私にとって今年最高の機能リリースでした。
データアクセス制御の新たなアプローチ：S3 Access Pointsの活用
データペリメーターポリシーが全体に適用されているかを確認するだけでなく、トラブルシューティングや監査が必要な問題がまだあることは承知しています。 お客様から最も多く寄せられる声の1つは、新しいアプリケーションのセットアップの難しさです。どこかで間違いを犯して403 Access Deniedが発生した場合、その原因がわかりません。ロールポリシー、バケットポリシー、VPCポリシーのトラブルシューティングが必要で、これには何時間もかかります。 8月に、アクセス拒否の理由に関する追加情報を提供する機能をリリースしました。この例では、Explicit Deny（明示的な拒否）が表示されており、このロールに対してアクセスを防ぐDenyステートメントが適用されていることを意味します。Implicit Deny（暗黙的な拒否）の場合は、Allowステートメントが不足していることを意味し、この例ではResource-based Policy、つまりバケットポリシーに問題があることを示しています。 多数のバケットがある場合、それらへのアクセス権限をスケーラブルな方法で監査したいと考えるでしょう。そのニーズに対応するためのダッシュボードを作成しました。
具体例を見てみましょう。このパネルでIAM Access Analyzer for S3を選択し、確認したいリージョンを選択すると、結果が表示されます。上部にパブリックアクセスが可能なバケット、下部には他のAWSアカウントからアクセス可能なバケットが表示されます。アクセスポイントポリシー、バケットポリシー、ACLを分析して結果を表示し、どのポリシーやACLがアクセスを許可しているかを示すので、必要に応じて変更を加えることができます。
データへのアクセスを監査することは非常に重要です。セキュリティ監査やコンプライアンス監査、あるいはデータアクセスパターンを理解するために、Server Access LogsとAWS CloudTrailログを有効にして活用できます。なぜ2つのログがあるのかと疑問に思われるかもしれませんが、これはAmazon S3が最も古いサービスの1つで、CloudTrailが登場する前からアクセスログを提供していたためです。CloudTrailは約10年の実績があり、最新の機能を備えているため、現在は CloudTrailの使用をお勧めしています。すでにServer Access Logsを使用している場合はそのまま継続していただいて構いませんが、新規の場合はCloudTrailが最適な選択でしょう。
これからBeckyが、データレイク内の構造化データと非構造化データのセキュリティ確保について、そしてAmazon S3でのスケーラブルなデータアクセス管理の高度な手法について説明します。しかし、その前に少し基本的な部分を整理させてください。データとそのアクセスに関しては、様々なパターンが存在するからです。
Amazon S3は他のAWSサービスの中でもユニークな存在です。とは言え、そこまでユニークではないかもしれません。というのも、Amazon S3バケットは、AWS LambdaやAmazon EC2インスタンスと同様、クラウドインフラストラクチャの一部だからです。管理アクションやデータアクションなど、すべてのアクションはIAMによって制御されます。この点では、Amazon S3は他のAWSサービスと変わりません。ただし、Amazon S3はデータストレージでもあり、バケットに保存されているデータの性質によって、その扱い方を考える必要があります。
多対多のデータアクセス管理：S3 Access Grantsの導入
Amazon S3にはあらゆる種類のデータを保存できますが、一般的に次のカテゴリのいずれかに分類されます。SQLクエリ、分析ツール、機械学習で利用する構造化データか、Amazon S3のフォルダで整理された非構造化データです。ご存知かもしれませんが、Amazon S3には実際のフォルダは存在せず、フォルダのように見えるスラッシュがあるだけです。これを私たちはプレフィックスと呼んでいますが、フォルダとして考えるのも実用的な方法です。そして最近では、生成AIのユースケースや検索拡張生成などで使用されるドキュメントの保存も増えています。
これはAmazon S3のデータについてですが、実際にはクラウドインフラストラクチャとしてのAmazon S3バケットの考え方と、データコンテナとしての考え方は、両方が同時に存在する少し異なるものです。多くの場合、大規模なData Lakeを含むAmazon S3バケットと、これらすべてのクラウドインフラストラクチャのユースケースが同時に発生することになります。
さらに詳しく見ていきましょう。ここではデータ側について説明します。というのも、多くの場合、スケールに関する質問はここで出てくるからです。非構造化データと構造化データについて、もう少し定義を説明させてください。これらは皆さんが想像する通りの意味です。非構造化データは何でもよく、一方で構造化データは通常、テーブル形式で構造化されており、ParquetやJSONなどの形式で保存されています。今回の説明において重要な違いは、構造化データは一般的にSQLクエリやデータのスキーマを参照する他の種類のアクションでアクセスされるという点です。Amazon S3の非構造化データの場合、インターフェースは一般的にS3 GetObject、PutObjectなど、ファイルレベルで扱うのに対し、構造化データへのアクセスはスキーマを意識したものになります。
最後に、アクセスコントロールについて説明します。アクセスコントロールの単位も実際には少し異なります。非構造化データの場合、ファイルやフォルダがその単位となります。先ほど申し上げたように、これらの言葉は実際にはAmazon S3には存在しませんが、おそらくそのように考えていることでしょう。一方、構造化データの場合、考慮すべきスキーマ全体があります。テーブル、カラム、行ベースのアクセスコントロールなど、データの内容と構造に関係するすべての要素があります。用途に応じて異なるツールがあり、実際には異なるユースケースに対して複数のツールを同時に使用することもあります。これから複数のユースケースを同時に見ていきましょう。
皆さんが新しい何かを学んでいただけることを願っています。データへのアクセスについて、4つの異なる考え方に分けて説明していきます。IAMともっと多くのIAMアプローチについて説明し、その後、多対多対多のアクセスパターンを持つ一般的なData Lakeのユースケースに似たケースを見ていきます。それらに適したツールについても説明します。
基本的なIAMアプローチから始めましょう。Megさんは既に多くのことを説明しましたが、私はデータの観点からこれを見ていきます。皆さんのほとんどは、画面に表示されているように、データについて考えていると思います。フォルダがあり、ここでは赤、黄、青の3つのフォルダを示していますが、各フォルダには、プロジェクトに携わっているか、あるグループの一員であるために、そのフォルダで作業する権限を持つ人々がいます。これが、ほとんどの人々のデータ組織に対する考え方です。
もちろん、通常はフォルダは3つだけではありません。 このスライドでは私が知っている限りの色を使って表現していますが、実際にはもっと多くのフォルダを持つことができます。Amazon S3バケットでは、このようなフォルダの数に実質的な制限はありません - これらは単にスラッシュで区切られた文字列にすぎません。ですが、ここでは3つに戻って、red、yellow、blueそれぞれにアクセス権を持つチームがある場合の実装方法について説明しましょう。
まずはバケットポリシーから始めましょう。blueスラッシュのプレフィックスに一致するすべてのオブジェクトへのアクセスを許可するバケットポリシーを作成できます。ここではワイルドカードを使用し、このアクセスがblue IAMロール用であることを指定しています。blueチームのメンバーがAWSにフェデレーションしてblueロールとしてAWSにアクセスできるように設定し、blueデータへのアクセスを提供します。ここで文字数を数えてみました - 251文字です。この数字は覚えておいてください。
blueチームは、オブジェクトの読み取りアクセスだけでなく、何があるのかを確認するためにオブジェクトをリストする必要もあります。そこで、もう1つのステートメントを追加します。プレフィックスblueの下でリストを表示する限り、バケットをリストできるようにします。これが基本的に私のバケットでblueチームが必要とするものです。文字数は554に増えました。
なぜこれらの数字をお伝えしているのでしょうか？それは計算が必要だからです。AWSでIAMベースのアプローチを取る場合、IAMはコントロールプレーンであるため、制限を意識する必要があります。S3バケットポリシーには20キロバイトの文字制限があります。オブジェクトの取得部分で約300文字、バケットのリスト部分で約300文字使用しました。計算すると、数十個のプレフィックスまで対応できることになります。プレフィックスが3つだけなら、これはIAMのルールに従った非常に分かりやすいアプローチです。しかし、数十個になると制限に近づくため、別のアプローチが必要になるかもしれません。
このアプローチをもっと柔軟にすることができます。必要なのはパラダイムの転換です。バケットにポリシーを設定でき、プリンシパルにもポリシーを設定できるので、プリンシパルに対するポリシーについて話しましょう。3つのフォルダと3つのIAMロールの話に戻りますが、バケットに大きな統合ポリシーを書く代わりに、各ロールに特化したポリシーを書きます。redロールにはポリシー、yellowロールにはポリシー、blueロールにはポリシーというように設定します。
ブルーのロールポリシーを見てみると、ポリシーサイズの制限についてはそれほど心配する必要はありません。ご覧の通り、これはかなりコンパクトな、シンプルなポリシーです。私はこれらそれぞれにロールを与えていますが、オレンジ色の友人がいます。 この人はレッドチームとイエローチームの両方に所属しています。実際、彼らの仕事は - レッドとイエローのデータを結合することに対して給料を支払っているのです。
しかし、レッドロールもイエローロールも彼らには機能しません。オレンジロールを作る必要があります。私はオレンジロールに対して、レッドのものとイエローのものへのアクセス許可を付与しました。ここでポリシー容量についてはあまり心配していませんが、少し数学的な知識があれば、これが順列と組み合わせの数による組み合わせ的な問題を引き起こすことがわかります。これが機能する場合もあれば、機能しない場合もあります。
スケールにおける制限要因は何か考えてみましょう。それは、このシナリオで必要となる個別の静的アクセスパターンの数です。IAMの制限は1000で、アカウントあたり5000ロールまで制限緩和を申請できますが、それ以上は実質的に不可能です。これは、明確に定義された約100のアクセスパターンがあり、それらに人々を振り分ける場合で、組み合わせがそれほど多くない場合に機能します。組み合わせがある場合、2のn乗になってしまうからです。つまり、個別のアクセスパターンが1000を大きく下回っている場合、ジョブごとに異なるロールを使用するアプローチは再び比較的単純で、うまく機能します。トリプルディジットに入り始めると、それが関連する制限となってきます。
ここまでは純粋にIAMベースのアプローチについて話してきました。 新しい概念は特に導入していません。IAMベースのアプローチすべてにおいて、これらの様々なスケールの次元を理解することが重要です：どれだけの個別パターンがあるか、異なるポリシーで何を表現しようとしているのか、そしてそれらの数値計算をチェックすることです。組織として、そしてAmazon S3でのデータ使用が拡大するにつれて、これらの数値を監視してください。ロールベースのアクセスについて話してきましたが、それが適している場所と適していない場所が見えてきたかもしれません。 それが適している場合でも、これらのIAM制限が障害となる場合について、その考えを保持しておいてください。
そこで、この解決策はより多くのIAMを使用することだと考えるかもしれません。 多くの場合、それは正解です。Amazon S3からより多くのIAMを引き出す方法について話していきましょう。実際に行える方法は2つあります。 同じIAMで、私たちができることの1つは、これらの色をバケット内のフォルダとして持つ代わりに、各データセットに対して異なるバケットを持つことです。 これは実現性が高くなりました。なぜなら、 最近、アカウントあたり1,000,003個のバケットを持てるようになったと発表されたからです。これはかなり大きな数字です。データセットごとに独自のバケットに整理できれば、それぞれを個別に管理でき、バケットポリシーの容量についてそれほど気にする必要がなくなります。各バケットが独自のポリシーを持ち、20KBの容量が使えるため、かなりシンプルになります。ここでは、より多くのIAMを活用できるようになります。
このアプローチは、データの取り扱いを始めたばかりで、データの保存場所について決定権がある場合には有効かもしれません。ただし、既存のS3バケット内にフォルダで整理された大量のデータがある場合には、適していないかもしれません。データを一括で移動するための優れたツールとして、S3のBatch Operationsという機能があります。このツールの使用をお勧めしますが、データの移動は面倒な作業であり、また新しい保存場所でデータを見つけられるようにアプリケーションを更新する必要があります。
構造化データのアクセス管理：AWS Lake Formationの活用
これは私たちのIAMアプローチの一つです。もう一つのアプローチを紹介しましょう - それがS3 Access Pointsです。 ここでも、データが実際にある場所なので、すべてを1つのバケットに戻してみましょう。これをどのように表現できるでしょうか？そうですね、 S3 Access Pointsを使用できます。S3 Access Pointsは、S3に数年前から実装されている機能です。これを理解する最良の方法は、バケットとしてではなく、バケットへの代替エンドポイントとして考えることです。Access Pointを作成すると、独自のDNS名が付与されることに気付くでしょう。S3バケットと同じように操作できます - データは元の場所で読み書きされます。重要なのは、Access Point自体が独自のIAMポリシーを持っているということです。つまり、Access Pointにポリシーがあり、S3バケットにもポリシーがあり、データにアクセスするにはその両方をパスする必要があります。これにより、ポリシーを異なる方法で
構成することができます。 たとえば、クレヨンの箱全体を取り出すように例えると、Access Pointを作成します。データはそのままの場所に置いておきますが、各フォルダに対してAccess Pointを作成します。ここでS3バケットポリシーはどうなっているのか気になるかもしれません。実は、非常にシンプルにしています。私のAccess Pointsのいずれかを経由してアクセスする場合は許可する、というポリシーを書いています。基本的に、権限をAccess Pointsに委譲しているわけです。各Access Pointには20KBのポリシーを設定できるので、より多くのIAM制御が可能になります。
データは元の場所に残りますが、S3 Access Pointを通じて代替エンドポイントを使用してデータにアクセスすることになるため、 アプリケーションコードを変更する必要があります。データは物理的な場所は変わりませんが、論理的な場所が異なります。これはAccess Pointsを使用する前の状態です - データがあるところに直接アクセスしています。purple/rainはこのバケットの中にあります。 同じオブジェクトにAccess Pointを通じてアクセスしてみましょう。バケット名が自動生成された文字列に変わっていることに気付くでしょう。これはS3によって生成されたバケットエイリアスで、このAccess Pointを経由することを意味します。末尾に-s3aliasという接尾辞が付いているのが特徴ですが、基本的にはS3バケットのように使用します。Access Pointを経由してそのポリシーが評価されます。
これを機能させるために必要なことを考えると、アプリケーションはバケットの代わりにAccess Pointを通じてデータにアクセスするように更新するか、その方法を見つける必要があります。しかし、それが可能であれば、より多くのIAM制御を得ることができます。Access Pointsについては、デフォルトで最大10,000のAccess Pointsを使用できます。 これはかなり多くのデータセットに対応できる数字で、さらに増やすこともできます。データは元の場所に残すことができ、S3バケットポリシーでガードレールやDeny文に焦点を当て、Access Pointポリシーで実際の許可を行うという素晴らしい特性があります。主な考慮点は、データの新しい論理的な場所を見つけるためにアプリケーションコードを変更できるかどうかということです。
IAMについて話し、さらにIAMについて話してきましたが、今度はAWSのIAMロールベースのアクセスコントロールモデルに本質的に内在する課題について話していきましょう。多くのケースではロールによってアクセスパターンを定義できるため、このモデルはうまく機能します。しかし、あまり適していないパターンもあります。 データレイクでは、ユーザーとデータへのアクセス権限をマッピングする必要性が非常に一般的です。ほとんどの組織、おそらくあなたの組織でも、従業員はディレクトリや他の記録システムの中で、いくつかのグループに所属しているという考え方をしています。大企業で働いている場合、おそらく非常に多くのグループに所属していることでしょう。つまり、あなたは異なる権限の独自の組み合わせを持っているわけです。隣の席の同僚とあなたでは、データに対する権限が少し異なっており、自分に与えられた権限のあるデータにはアクセスできますが、権限のないデータにはアクセスできないようにする必要があります。
では、円グラフメーカーを作ってみましょう。そして、それを自分たちでどのように構築するかについて話していきます。AWSのAnalyticsやMachine Learningサービスも、非常によく似た形で構築されています。この円グラフメーカーを作るのは、上司が円グラフを見るのが大好きだからです。右上に示されているようなデータアクセススキームがあるので、これを確実に実施する必要があります。 Amazon EC2で実行するのは良い選択です。AWSのコンピューティングの素晴らしい点は、IAMロールを提供し、認証情報の配布を処理してくれることです。そこで、円グラフメーカーアプリケーションを表すIAMロールをEC2インスタンスに関連付けます。データの取得方法を考えると、この円グラフメーカーには多くのユーザーがいて、それぞれが適切なデータセットで円グラフを作成できるようにしたいと思います。そのため、ビジネスロジックでこのデータアクセススキームを実施する必要があります。素晴らしい、みんな満足です - 適切な人が適切なデータで適切な円グラフを作成しています。そして、上司が辞めました。新しい上司は棒グラフが大好きなんです。
「円グラフなんていらない、棒グラフがいい」ということで、代わりに、あるいは追加で（まだ円グラフが好きな人もいるので）棒グラフメーカーを作ることになりました。もちろん、このアクセススキームは引き続き実施する必要があります。今回は最新化してAWS Lambdaでサーバーレスに構築します。ただし、基本的な話は同じです - 棒グラフメーカーアプリケーションにIAMロールを関連付け、これもアクセス制御メカニズムを実装することになります。
ここにいるほとんどの方はエンジニアなので、同じものを2回実装すると3回間違えることになるというのはご存知でしょう。これは少し問題です。ビジネスロジックで同じことを2回実装しなければならず、一貫性の確保が課題となります。ユーザーとデータのマッピングを2か所で行う必要があり、できれば1か所で済ませたいところです。 もう1つの関連する課題は、円グラフメーカーがAmazon S3のデータにアクセスする際、アプリケーションとして、つまり自身としてアクセスするということです。Megが説明したように、AWS CloudTrailをS3に対して有効にし、データイベントを有効にしてS3のオブジェクトにアクセスした人を確認すると、完全に正しい応答が得られます。それは、円グラフメーカーアプリケーションロールがオブジェクトにアクセスしたということです。
しかし、それは実際にあなたの質問に直接答えているわけではありませんよね？あなたはそのグラフを誰が見ていたのかを知りたかったのに、そのコンテキストは伝わってきません。もちろん、従来のAWSにはこの問題に対する多くの解決策があります - 適切な使用記録を持ち、すべての点をつなぎ合わせる必要があるだけです。ここでは、マゼンタ色のユーザーが円グラフを作成しています。実際には、このデータアクセスを主導したのが誰だったのかという記録がCloudTrailに残っていてほしいところです。これが1つの課題となっています。
このように、多対多の役割ベースではないアクセス制御シナリオには2つの大きな課題があります。Amazon S3では、この問題を解決するために2つのアプローチがあります。1つは非構造化データ向けのS3 Access Grantsで、もう1つはAWS Lake Formationです。この2つのアプローチのどちらを使うかは、データの種類によって決まります。非構造化データにはS3 Access Grants、構造化データにはLake Formationを使用します。実際には、同じデータでも非構造化として扱うケースと構造化として扱うケースがあるため、両方を同時に使用することも可能です。
非構造化データとは、ファイルごとにGetObjectやPutObjectを行い、オブジェクトの中身にはあまり注目しないパターンを指します。一方、構造化データは、オブジェクトの中身やスキーマを重視し、アクセス制御の単位はテーブルやカラムになります。このように2つの異なるアプローチがあります。非構造化データについては、約1年前にリリースされたS3 Access Grantsについて説明します。また、Lake Formationについても触れます。これらは両方とも、IAM Identity Centerサービスとの統合により、ユーザーIDを直接サポートしています。多くの方が従業員のアカウントアクセスの設定に使用しているのと同じサービスです。
これは実際には異なるカテゴリの機能です。AWSに同期したアイデンティティを、Amazon S3やLake Formationのようなデータシステムにまで伝播させる機能です。約1年前にリリースされたので、比較的新しい機能です。では、S3 Access Grantsについて、多対多の問題をどのように解決できるのか見ていきましょう。S3 Access Grantsの例をお見せしますが、これが最も理解しやすい方法です。
ここでのアクセス単位はS3のプレフィックスで、フォルダレベルのアクセスは非常にシンプルに読み取り、書き込み、読み書きとなっています。そして、付与先（grantee）に注目してください。これが先ほど説明したIdentity Centerとの統合部分です。付与先は実際には、Active DirectoryやOktaなどのディレクトリグループを指しています。つまり、ユーザーがグループを離れたり参加したり、組織内で異動したりしても、権限は自動的に更新され、中間のマッピングシステムを管理する必要がありません。
これがS3 Access Grantsです。このアプローチで私たちの問題をどのように解決できるのでしょうか？円グラフメーカーと棒グラフメーカーの例に戻ってみましょう。以前は、このアクセススキームを2回実装しなければならず、それが問題でした。S3 Access Grantsは、複数の場所でスキームを定義して適用する代わりに、S3 Access Grantsを通じて1か所で実装することを可能にすることで、この問題を解決します。
私たちは、Pie Chart MakerとBar Graph Makerの両方をこれに統合するよう更新しました。その詳細については後ほどご説明させていただきます。現在、Access Gateを一度実装しています。さらに、ユーザーがこのAccess Gateを通過すると、Identity Centerのトラステッド・アイデンティティ・プロパゲーション機能によって、そのアイデンティティが伝播されます。これは、ユーザーのアイデンティティがS3まで遡る場合と同様のプリミティブです。S3のCloudTrailを確認すると、ユーザーを特定できるユーザー識別子が表示され、マゼンタ色のユーザーがアクセスしているのが分かります。S3 Access GrantsとLake Formationは、多対多のアクセスに関するこれら二つの課題を解決します。
実際にこの仕組みがどのように機能するのか、これを基に開発する場合について説明しましょう。まず、Access Grants導入前のS3でのオブジェクトアクセスについて見てみましょう。ここでは、データアプリケーションがバケットとオブジェクトのキーを使ってget objectを実行しています。S3 Access Grantsを使用すると、プロセスが異なります。なぜなら、Pie Chart Makerアプリケーションはもはやデータへの常時アクセス権を持っていないからです。まずユーザーから認証済みセッションを取得し、Access Grantsを認可ゲートまたはポリシー決定ポイントとして使用します。許可された場合のみ、S3 Access Grantsから一時的なIAMセッションが成功レスポンスとして返されます。その後、ユーザーのアイデンティティが組み込まれた一時的なIAMセッションでデータにアクセスします。
私たちは、AWS SDKs、特にJavaとboto3 Pythonで、これを簡単に実装できるよう改良を加えました。異なるプログラミング言語を使用している場合でも、S3 Access Grantsは利用可能です。ただし、この初期化シーケンスのために4行程度のコードを書く必要があります。変更点はすべてクライアントの初期化シーケンスにあります。ここではbotoプラグインをお見せしています。S3 Access Grantsに対応したboto用のプラグインをインストールし、それを使ってS3クライアントをインスタンス化すると、バックグラウンドでS3とのやり取りを行います。
しかし、それすら必要ありません。今年のre:Inventで、Transfer Familyアプリケーションを通じてこの機能をリリースしました。これは、マネージドSFTPなどの機能を提供するAWSのサービス領域です。Transfer Family Web Appsを使用すると、アイデンティティ統合でS3 Access Grantsにいくつかのグラントを定義し、ワンクリックでAccess Grants用の基本的なアプリケーションを生成できます。ユーザーはURLにアクセスし、SSOで設定したディレクトリに送られます。青グループと赤グループの両方に所属する紫色のユーザーがサインインすると、青フォルダと赤フォルダの両方が表示されます。ログアウトして青色のユーザーがログインすると、青フォルダだけが表示されます。これは、S3がデータ共有やコラボレーションに便利な方法であるという、皆さんが抱えているかもしれない問題を解決する非常に有用な機能です。このアプリケーションは、オープンソースのUIコンポーネントであるS3 Object Browserを基に構築されています。アプリケーションを自分で構築したくない場合でも、S3のアップロードやダウンロード用のホステッドUIが必要な場合、あるいは独自のUXを構築したい場合は、S3 Object Browserを検討することをお勧めします。S3 Object Browserは、私たちがオープンソース化した再利用可能なコンポーネントです。
S3 Access Grantsは、デフォルトで最大10万件までスケーリング可能です。これにより、多対多のマッピングを異なる場所で定義する必要がなくなり、監査コンテキストが失われがちな中間のロールの問題も解決します。非構造化データを含むデータレークのユースケース、つまりオブジェクト単位でデータにアクセスするユースケースでは、これは非常に良い選択肢となります。ただし、考慮すべき点として、アプリケーションの初期S3クライアント初期化シーケンスを更新する必要があります。S3で実際に処理を行う部分は更新する必要はありませんが、JavaやPythonの場合はプラグインを使用するか、自分でコードを数行書くことで、初期化シーケンスを更新する必要があります。これが可能であれば、S3でスケーラブルなエンドツーエンドのアクセスと監査の仕組みを、より優れた形で実現できます。
構造化データ、つまりテーブル、カラム、行、スキーマを持つデータについて話す際、S3 Access Grantsに対応するのがAWS Lake Formationです。AWS Lake FormationはAWSのAWS Glue Data Catalogと密接に連携しています。AWS Glue Data CatalogはAWSにおける分析用データカタログであり、構造化データのためのメタストアです。AWS Glue Data CatalogはS3、Amazon Redshift、その他多くのAWSサービス上のデータを包括的にカタログ化します。実は、Lake FormationはAWS Glue Data Catalogの一部として機能しており、構造化データの権限管理にはデータのスキーマを参照する必要があるため、AWS Glue Data Catalogのパーミッションシステムとして働いています。
Lake Formationによる詳細なデータアクセス制御の実現
S3ではスキーマを認識できないため、メタデータレイヤーでこれを行う必要があります。なぜなら、 S3にとってオブジェクトはただのオブジェクトだからです。ここにS3上の構造化データがありますが、分析に携わる方なら、これらがParquetファイルの名前であることをご存知でしょう。しかし、S3にとってはこれらの名前を持つオブジェクトが存在するということしかわかりません。 見やすくするために、CSVで例を示しましょう。ここには明らかに、ヘッダーとカラムを持つテーブルがあります。
権限管理の観点から考えると、これは明らかに人々の地理的位置情報と、何らかのトランザクション、そして価格を含むテーブルです。これらの異なるカラムの機密性に応じて、データの利用者ごとにテーブルの異なる部分、つまりS3オブジェクト内の異なる部分へのアクセス権限を設定したいかもしれません。管理者ユーザーには全てを閲覧できるようにして、select *を実行すると全てのカラムが表示されるようにしたい一方で、機密データと考えられる地理的位置情報は他のユーザーには表示したくないかもしれません。そのため、そういったユーザーがselect *を実行した際には、アクセス権のある情報のみを表示させたいわけです。
IAMについて多くの時間を費やしてきたので、これを解決する方法を考えてみましょう。 GetObjectを使用してポリシーを書き始めます。S3上のオブジェクトの場所はわかっています。では、あるユーザーがselect *を実行すると全てが表示され、別のユーザーが実行すると一部しか表示されないようにするには、どんな条件を書けばよいでしょうか？ IAMもS3も、カラムが何かを知りません。S3はオブジェクトしか知らないため、カラムという概念を理解できません。IAMは非常に文字通りの解釈しかできず、リクエストを承認すると、その後の結果については関与しません。
では、どうすればよいのでしょうか？これが、AWS Glueレベルで処理する必要がある理由です。スキーマについて扱えるものが明らかに必要で、それこそがLake Formationの役割なのです。 ここでLake Formationのグラントの簡単な例をお見せします。2つのカラムだけを閲覧できるデータユーザーに対して、実際にカラムレベルの権限を付与していることに注目してください。全てのカラムへの権限は与えていません。S3にはできず、IAMにもできないことです。 では、これはどのように機能するのでしょうか？例えば、Amazon Athenaを通じてこのクエリを実行する場合を考えてみましょう。
Athenaのクエリエンジンがどのように動作するか考えてみましょう。まず、スキーマを取得するためにAWS Glue Data Catalogにアクセスする必要があります。GlueはAWS Lake Formationと統合されているため、リクエストしているユーザーに基づいて表示すべきカラムを把握しています。Glueからメタデータを取得した後、データを読み取るために必要な権限をLake Formationに確認します。GlueがS3上のデータの場所を教えてくれるので、Lake FormationがS3へのアクセス権を付与します。これはS3 Access Grantsと似ているように聞こえますが、実際そうなのです。Lake Formationが判断を下し、S3がAthenaにデータ読み取りの権限を与えます。
もちろん、S3はカラム情報を把握していないため、すべてのデータがAthenaに送り返されます。フィルタリングを行うのはAthenaの役割です。AthenaはLake Formationからフィルタリングの指示を受け取ります。実際にデータをフィルタリングできるのはコンピュートエンジンの段階になってからなので、追加の連携が必要になります。これが動作の仕組みです。
Lake Formationを使うべきでしょうか？これは、AWSでアナリティクス関連のサービスを使用して構造化データを扱う場合、非常に簡単に答えられる質問です。Lake Formationを使うべきです。AWS Glue Data Catalogにデータカタログを持つべきで、そこには様々な種類のコネクタに対応する豊富な機能があります。私が説明した基本的なシナリオはとてもシンプルです。構造化データを扱う場合は、アナリティクスのエコシステムにおける権限管理やその他のETL機能を効果的に活用するために、Glue Data Catalogについて必ず学んでおくべきです。
Lake Formationはアイデンティティと統合されています。つまり、先ほどお見せしたLake Formationの権限付与は、ディレクトリ内のユーザーやグループではなく、IAMプリンシパルを参照していました。ただし、S3 Access Grantsでお見せしたように、ユーザーやグループを参照することもできます。このグループはこのテーブルにアクセスできるが、これらのカラムにはアクセスできないといった権限を設定できます。このような権限を付与でき、アナリティクスエンジンがそれを適切に実施します。これにより、アナリティクスに関する包括的なアイデンティティの仕組みが実現できます。
S3におけるデータアクセス管理の総括
以上が4つの異なるアプローチであり、その中の少なくとも1つは新しい発見があったのではないでしょうか。多くの場合、スケールの規模やアクセスパターンによって適切な選択が変わってきます。静的なロールベースのアプローチでは、現在のIAMの規模を超えるように見える場合でも、小規模から中規模向けのIAMアプローチがあります。さらに、IAMが適している場合は、より多くのバケットやアクセスポイントを使用するIAMアプローチもあります。ロールベースではなく、多対多の関係でデータレイクのような形態の場合は、非構造化データにはS3 Access Grants、構造化データにはLake Formationについて説明しました。
以上が本日お話しした内容です。まず基本的な部分として、S3がデフォルトで既に安全に作られているということ、実はこの講演に来なくても私たちが既に対策済みだということをお話ししました。次に、IAMとS3の基本原理について理解を深めていただきました。最後に、大規模なS3における詳細なアクセス制御を実現するための4つの方法についてご説明しました。これらの中から、皆様のユースケースに合った方法が見つかることを願っています。re:Inventでの今週が素晴らしいものとなり、残りの日程も、そして今夜のパーティーもお楽しみいただければと思います。ご参加いただき、ありがとうございました。データアクセスの実装がうまくいきますように。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion