AWS S3 バケット内でアクセス権オーケストレーションを自動化する方法

公開: 2023-01-13

数年前、大規模なファイルシステムを備えたオンプレミスの Unix サーバーが話題になったとき、企業はさまざまなユーザーのさまざまなフォルダーへのアクセス権を管理するための広範なフォルダー管理ルールと戦略を構築していました。

通常、組織のプラットフォームは、完全に異なる関心、機密レベルの制限、またはコンテンツ定義を持つさまざまなユーザーグループにサービスを提供します。グローバルな組織の場合、これは、場所に基づいてコンテンツを分離することを意味することもあります。つまり、基本的には、異なる国に属するユーザー間です。

さらに典型的な例は次のとおりです。

開発、テスト、本番環境間のデータ分離
幅広い視聴者がアクセスできない販売コンテンツ
別の地域内からは表示またはアクセスできない国固有の立法コンテンツ
「リーダーシップデータ」が限定されたグループにのみ提供されるプロジェクト関連のコンテンツなど。

そのような例の潜在的に無限のリストがあります。ポイントは、プラットフォームがアクセスを提供するすべてのユーザー間で、ファイルとデータへのアクセス権を調整する何らかの必要性が常にあるということです。

オンプレミスソリューションの場合、これは日常的な作業でした。ファイルシステムの管理者は、いくつかのルールを設定し、選択したツールを使用しただけで、ユーザーがユーザーグループにマップされ、ユーザーグループが、アクセスできるフォルダーまたはマウントポイントのリストにマップされました。その過程で、アクセスのレベルは読み取り専用または読み取りと書き込みアクセスとして定義されました。

AWS クラウドプラットフォームを調べてみると、人々がコンテンツアクセス制限に対して同様の要件を持っていることを期待することは明らかです。しかし、この問題の解決策は、今では異なっているはずです。ファイルは Unix サーバーではなくクラウドに保存され (組織全体だけでなく全世界からアクセスできる可能性があります)、コンテンツはフォルダーではなく S3 バケットに保存されます。

以下に説明するのは、この問題に対処するための代替手段です。これは、具体的なプロジェクトのためにそのようなソリューションを設計していたときの実際の経験に基づいて構築されています。

シンプルだが膨大な手作業によるアプローチ

自動化を行わずにこの問題を解決する 1 つの方法は、比較的単純で単純です。

個別のグループごとに新しいバケットを作成します。
この特定のグループのみが S3 バケットにアクセスできるように、バケットにアクセス権を割り当てます。

これは、要件が非常に単純で迅速な解決策を採用することである場合、確かに可能です。ただし、注意すべき制限がいくつかあります。

デフォルトでは、1 つの AWS アカウントで作成できる S3 バケットは最大 100 個です。この制限は、サービス制限の引き上げを AWS チケットに送信することで 1000 まで拡張できます。これらの制限が特定の実装ケースで懸念されるものではない場合は、個別のドメインユーザーのそれぞれが個別の S3 バケットで操作できるようにし、それを 1 日と呼ぶことができます。

複数の部門にまたがる責任を負っている人々のグループや、より多くのドメインのコンテンツに同時にアクセスする必要がある人々がいる場合、問題が発生する可能性があります。例えば：

いくつかの異なる地域、地域などのデータコンテンツを評価するデータアナリスト。
テストチームは、さまざまな開発チームにサービスを提供するサービスを共有しました。
同じ地域内のさまざまな国の上にダッシュボード分析を構築する必要があるレポートユーザー。

ご想像のとおり、このリストは想像を絶するほど大きくなる可能性があり、組織のニーズはあらゆる種類のユースケースを生み出す可能性があります。

このリストが複雑になるほど、組織内の異なる S3 バケットへの異なるアクセス権をすべての異なるグループに付与するために、より複雑なアクセス権オーケストレーションが必要になります。追加のツールが必要になり、専用のリソース (管理者) でさえ、アクセス権リストを維持し、変更が要求されるたびにそれらを更新する必要があります (特に組織が大規模な場合、これは非常に頻繁になります)。

では、より組織的かつ自動化された方法で同じことを達成するにはどうすればよいでしょうか?

バケットのタグを導入する

ドメインごとのバケットアプローチが機能しない場合、他のソリューションでは、より多くのユーザーグループに対して共有バケットが使用されます。このような場合、動的に変更または更新しやすい領域にアクセス権を割り当てるロジック全体を構築する必要があります。

これを実現する方法の 1 つは、S3 バケットでタグを使用することです。タグは、どのような場合でも使用することをお勧めします (課金の分類を容易にする以外の目的がない場合)。ただし、タグは将来いつでも、どのバケットでも変更できます。

ロジック全体がバケットタグに基づいて構築され、残りの部分がタグ値に依存する構成である場合、タグ値を更新するだけでバケットの目的を再定義できるため、動的プロパティが保証されます。

これを機能させるには、どのような種類のタグを使用すればよいですか?

これは、具体的なユースケースによって異なります。例えば：

環境タイプごとにバケットを分ける必要がある場合があります。したがって、その場合、タグ名の 1 つは「ENV」のようなもので、可能な値は「DEV」、「TEST」、「PROD」などになります。
国に基づいてチームを分けたいと思うかもしれません。その場合、別のタグは「COUNTRY」で、国名を値にします。
または、ビジネスアナリスト、データウェアハウスユーザー、データサイエンティストなど、ユーザーが属する機能部門に基づいてユーザーを分離することもできます。そのため、「USER_TYPE」という名前とそれぞれの値を持つタグを作成します。
もう 1 つのオプションは、特定のユーザーグループが使用する必要がある固定フォルダー構造を明示的に定義することです (独自のフォルダーの混乱を作成し、時間の経過とともにそこで失われないようにするため)。「data/import」、「data/processed」、「data/error」などのいくつかの作業ディレクトリを指定できるタグを使用して、これを再度行うことができます。

理想的には、タグを論理的に結合してバケット上のフォルダー構造全体を形成できるようにタグを定義する必要があります。

たとえば、上記の例の次のタグを組み合わせて、さまざまな国のさまざまなタイプのユーザー専用のフォルダー構造を構築し、ユーザーが使用すると予想される定義済みのインポートフォルダーを作成できます。

/<ENV>/<ユーザー_タイプ>/<国>/<アップロード>

<ENV> の値を変更するだけで、タグの目的を再定義できます (テスト環境のエコシステム、dev、prod などに割り当てるかどうか)。

これにより、多くの異なるユーザーが同じバケットを使用できるようになります。バケットはフォルダーを明示的にサポートしていませんが、「ラベル」はサポートしています。これらのラベルは、最終的にはサブフォルダーのように機能します。これは、ユーザーがデータに到達するために一連のラベルを通過する必要があるためです (サブフォルダーの場合と同様)。

動的ポリシーを作成し、内部でバケットタグをマップする

使用可能な形式でタグを定義したら、次のステップは、タグを使用する S3 バケットポリシーを構築することです。

ポリシーがタグ名を使用している場合、「動的ポリシー」と呼ばれるものを作成しています。これは基本的に、ポリシーがフォームまたはプレースホルダーで参照しているタグ値が異なるバケットに対して、ポリシーの動作が異なることを意味します。

このステップには明らかに動的ポリシーのカスタムコーディングが含まれますが、Amazon AWS ポリシーエディターツールを使用してこのステップを簡素化できます。

ポリシー自体では、バケットに適用される具体的なアクセス権と、そのような権利のアクセスレベル (読み取り、書き込み) をコーディングする必要があります。ロジックはバケットのタグを読み取り、バケットにフォルダー構造を構築します (タグに基づいてラベルを作成します)。タグの具体的な値に基づいてサブフォルダーが作成され、必要なアクセス権がそれに沿って割り当てられます。

このような動的ポリシーの優れた点は、動的ポリシーを 1 つだけ作成して、まったく同じ動的ポリシーを多数のバケットに割り当てることができることです。このポリシーは、異なるタグ値を持つバケットに対して異なる動作をしますが、そのようなタグ値を持つバケットに対する期待に常に沿っています.

これは、多数のバケットに対して組織化された一元化された方法でアクセス権の割り当てを管理するための非常に効果的な方法です。すべてのバケットが、事前に合意されたいくつかのテンプレート構造に従い、ユーザーが内部で使用することが期待されます。組織全体。

新しいエンティティのオンボーディングを自動化する

動的ポリシーを定義して既存のバケットに割り当てた後、ユーザーは、異なるグループのユーザーが、所有していないフォルダー構造の下にあるコンテンツ (同じバケットに保存されている) にアクセスできないというリスクなしに、同じバケットの使用を開始できます。アクセス。

また、より広いアクセス権を持つ一部のユーザーグループの場合、データはすべて同じバケットに保存されるため、簡単にアクセスできます。

最後のステップは、新しいユーザー、新しいバケット、さらには新しいタグのオンボーディングをできるだけ簡単にすることです。これは別のカスタムコーディングにつながりますが、過度に複雑である必要はありません。ただし、オンボーディングプロセスに、シンプルで直接的なアルゴリズムロジックでカプセル化できる非常に明確なルールがあると仮定します (少なくとも、この方法で、プロセスにはいくつかのロジックがあり、過度に混沌とした方法で行われることはありません)。

これは、新しいエンティティをプラットフォームに正常にオンボードするために必要なパラメーターを使用して、AWS CLI コマンドで実行可能なスクリプトを作成するのと同じくらい簡単です。たとえば、次のように、特定の順序で実行可能な一連の CLI スクリプトにすることもできます。

create_new_bucket(<ENV>,<ENV_VALUE>,<COUNTRY>,<COUNTRY_VALUE>, ..)
create_new_tag(<bucket_id>,<tag_name>,<tag_value>)
update_existing_tag(<bucket_id>,<tag_name>,<tag_value>)
create_user_group(<user_type>,<country>,<env>)
等

あなたは要点を理解します。

プロのヒント

必要に応じて、上記の上に簡単に適用できるプロのヒントが 1 つあります。

動的ポリシーは、フォルダの場所へのアクセス権の割り当てだけでなく、バケットとユーザーグループへのサービス権限の自動割り当てにも利用できます。

必要なのは、バケットのタグのリストを拡張し、動的ポリシーアクセス権を追加して、具体的なユーザーグループに特定のサービスを使用することだけです。

たとえば、特定のデータベースクラスタサーバーへのアクセスも必要とするユーザーグループが存在する場合があります。これは、サービスへのアクセスが役割ベースのアプローチによって駆動される場合、バケットタスクを活用する動的ポリシーによって確実に達成できます。データベースクラスター仕様に関するタグを処理する部分を動的ポリシーコードに追加し、その特定の DB クラスターとユーザーグループにポリシーアクセス権限を直接割り当てるだけです。

このように、新しいユーザーグループのオンボーディングは、この 1 つの動的ポリシーだけで実行できます。さらに、動的であるため、同じポリシーを再利用して多くの異なるユーザーグループをオンボーディングできます (同じテンプレートに従うことが期待されますが、必ずしも同じサービスである必要はありません)。

バケットとデータを管理するための AWS S3 コマンドもご覧ください。