Advanced security patterns on Amazon S3 [REPEAT]

セッション概要

• タイトル：Advanced security patterns on Amazon S3 [REPEAT]
• 日付：2024年12月2日(月)
• Venue： Caesars Forum | Level 1 | Academy 414
• スピーカー：
  • Akshat Sandh(Sr. PMT – External Svcs, Amazon)
  • Bryant Cutler(Principal Engineer, Amazon Web Services)
• 業界：
  • Professional Services
  • Software and Internet
• 概要：Amazon S3 のセキュリティ設定とアクセス制御についてより深い内容で紹介するセッションです。このセッションでは、大規模アクセスを管理するための検証済みパターンを確認できます。アクセス制御ポリシーの使用を最適化し、AWS Identity and Access Management（IAM）ポリシーの制限を超えて拡張し、データレイク境界を保護する方法を紹介しました。

はじめに

AWSの最初のサービスはS3であることを覚えていますか？ 2006年3月14日に発売したS3は、これまでなかったオブジェクトストレージという概念を初めて商用化したストレージサービスでした。 その後、この概念は他のストレージサービスに影響を与え、コンピューティングエコシステムを支配する有力企業(Google、Microsoft、OpenStackなど)が競ってサービスを発売しました。

Google Cloud Storage (2010年)、Microsoft Azure Blob Storage (2010年)、OpenStack Swift (2010年、オープンソース)がそれです。まだ扱ったことがない方は、これらの違いを体験してみるのもいいかもしれません。

私はOpenStackのSwiftを通じてオブジェクトストレージの概念を知ったのですが、当時、大きく戸惑った記憶があります。既存の私が経験したブロックストレージ、ファイルシステムストレージとはあまりにも違う経験をしたからです。

ブロックとファイルシステム基盤のストレージしか存在しなかったOn-premiseの時代を過ぎ、オブジェクトストレージの時代に入り、私たちはよりCloud-Nativeな環境に変化していると思います。

川が海に集まるように、すべてのデータはS3に集まりますが、私たちはS3についてどれだけよく知っているのでしょうか。

まるでS3は空気のようなもので、簡単につなげて使うことができますが、より複雑で高いセキュリティを要求されると、このような議論をしたことを思い出し、冷静に受け止めたいと思います。

信じられないほど多くのセキュリティー要件を受け入れているS3のポリシーと、このS3のアーキテクチャに集中してもっと正しく認識するきっかけになればと思います。

ポリシーのためのMentalモデル（私たちがAWSのリソースポリシーを理解する方法）

1番目のパターンでは、メンタルモデルという言葉が出てきますが、私たちが世界と相互作用するときに使用する認知的構造を意味し、心理学から出た概念なので、より深く入ることはありません。

私のような場合、「PrincipalがResourceにActionすることをEffectする」と政策構成を円滑にするために簡単な言葉を作ってみますが、このような認知構造が権限を記述するのに自然だと思います。 

主体（Principal）がリソース（Resource）に何かの行為（Action）をすることに対して許可をするのか、拒否するかに対する影響または意思決定（Effect）をポリシーとして記述すると、権限に対する頭の中の考えがポリシーを表現する文章で記述することと実際にそのように書かれたポリシーがそのように動作することになるそこで、S3のリソース政策もPEAR(Principal, Effect, Action, Resourceの略)をコック撮って悩む方です。

講演者Bryantは、政策を作成する際には2つを必ず考えなければならないと言うが、一つはboundary vs。 path で identity ポリシーを制限する permission boundary と S3 リソースを意味する data path で、具体的には S3 バケット、S3 バケット内のオブジェクト (object) を意味します。

Boundary は、Identity に付与される権限を制限する権限境界を意味します。Identity の権限が AmazonS3FullAccess であっても、Boundary が AmazonS3ReadOnlyAccess に制限されている場合、これらの 2 つの交差点である AmazonS3ReadOnlyAccess の権限のみが付与される結果を表示できます。

この Boundary はグローバルな効果があるため、すべてのリソースに影響を与えます。また、Boundaryに一部のサービスの権限を記述するようになると、記述しない領域に対して強力な制限を加えることになりますので、適用前に十分な考慮が必要です。

たとえば、Boudary に AmazonS3ReadOnlyAccess 権限のみが記述されている場合、Identity の権限が AdministratorAccess であっても、その集合である AmazonS3ReadOnlyAccess 権限のみが有効になります。

したがって、システムを構築する時点では、Boundaryの使用はあまり考慮されません。構築完了後、ControlTowerやOrganizationサービスを活用して、マルチアカウントの一括的なセキュリティポリシーの適用時にSCP（Service Control Policy）方式で適用するのが一般的です。

結論として、Boundaryはグローバルであり、制限を強制し、制度遵守とセキュリティに焦点を当てています。

これに対して path はバケット、バケット内のオブジェクトを表現する具体的なリソースを表し、アプリケーションがアクセスする具体的な対象、あるいはフォルダの場合フォルダ内のすべてのオブジェクトを表すため、データの活用に焦点が当てられています。

もう一つはPrincipal vs。リソースとして「資源に接近する主体（Principal）」と「主体のアクションに対応するリソース（Resource）」に対する認知が必要ですが、この件については私も強く同意します。

権限のスキルが必要な時点で権限が定義されていない状況を考えてみましょう。ホワイトペーパーで権限を定義する時点で、すべての権限は「アクセス者」と「アクセス対象」が何であるかから考えを始めることができます。

最小権限の法則（セキュリティで常に強調されるもの）制御

セキュリティで常に強調される最小限の法則があり、AWSでも例外ではありません。私たちは、SAとしての仕事のために提供されていたAWSのIAM-userを、セキュリティが強化されたお客様からはIAM-roleを通じてアクセスするように制御される場合があります。

講演者Bryantは、S3のアクセス制御にIAM-userを使用するよりも、必要に応じて権限を付与するToken Vending Machineの概念を主張します。 より短い時間、より少ない権限が必要な場合にのみ付与して割り当てる概念です。

特別なことは、クライアントであるアプリケーションとサーバーロールのS3バケットの間でリソースアクセスが発生するのではなく、クライアントはサーバーから一時的なセキュリティ資格情報のみを受け取り、ユーザーに渡し、ユーザーが一時的なセキュリティ資格情報を持つようにして、ユーザーに対応するリソースにアクセスさせる方法です。

その例には、事前署名URL方式、オンデマンド要求シグナ方式、およびS3 Access Grantsがあります。

アプリケーションがアクセスしたこの観点は、サーバーが最終ユーザーに最終結果であるリソースまで伝える伝統的な方法とは異なり、やや見慣れない使用方法でした。今後もう一度このセッションを復活してみたいですね。

権限問題解決のための果敢さ（設定変更を検知して元に戻す）

Bryantは、権限修正の永遠の障害物である「既存ユーザーの反発」を回避するために果敢になる必要があると言います。

運用中のサービスに新しいセキュリティまたは強化されたセキュリティを適用することは非常に困難であり、パフォーマンスを達成するのは困難ですが、AWSの多数のサービスを連携させることで、イベントベースのアーキテクチャでこれを克服できます。

スクリーンショットの例のように、特定リソースのBlock Public Access設定変更をSecurityHubに渡し、SecurityHubはFindingsを確認し、イベントをTriggerしてLambdaが動作させれば設定変更を元に戻すことができるアーキテクチャです。

もちろん、このアーキテクチャは一例に過ぎず、使用されているサービスと設定をより慎重に検討する必要があります。

Recap

最終的に以下のように要約できます。

• リソースポリシーを設定するときは、boundaryを設定するのか、data pathを有効にするのか、または適切なポリシータイプを使用します。
• IAMの使用にとらわれず、AWSアクセス制御を拡張するために一時資格自動発行（VTM）パターンを利用する
• 意図しない誤った構成の効率的な校正のためにサーバーレスモニタリングを使用する

まとめ

S3を使って、敷地不食の間にわかるように使う自分を振り返ります。 S3はリソースの象徴に過ぎず、すべてのリソースには彼の方法に合ったリソースポリシーがあり、私たちはそれを最大限に使用する必要があります。そして、コード開発者に適切なガイドとより良いセキュリティ対策を提供することも必要です。

S3はオブジェクトストレージとしてバケットだけでなく、オブジェクト一つ一つに対する細かい調整が可能です。これはAWSコンソールでしか達成するのが難しい部分があり、コード作成によるアプローチが導入されたアーキテクチャの理解に効果的に見えます。 

だから、ここ2年で私はShell ScriptよりもPython Scriptを書くのにもっと時間を費やしています。さらに、Pythonを介してSDK（boto3）を介したAPIアクセスへの思考の拡張を経験しました。この経験が個人の努力で達成可能かどうかは分かりませんが、確かなのは昨日より良くなる今日があるということです。 SAとしてセキュリティと開発に関心を持たない理由です。

記事 │MEGAZONECLOUD　Strategic Technology Center（STC）　CS1グループ　CA1チーム　イ・テフンSA