[レポート] Hands-on with Zero Trust: Building secure application architecture #AWSreInforce #IAM352

はじめに

こんにちは、コンサルティング部の神野です。

米国東海岸で開催されているAWS re:Inforce 2025に現地参加しています。

今回の記事では、re:Inforce 2025のBuilders' sessionの1つ、「IAM352: Hands-on with Zero Trust: Building secure application architecture」についてレポートします。

本セッションではLambda関数の直接呼び出しやサービス間の権限管理に対して改善を図るハンズオンセッションとなります。Amazon Verified Permissionsは使用したことがなかったため大変勉強になりました。

セッション概要

セッション番号: IAM352
セッションタイトル: Hands-on with Zero Trust: Building secure application architecture
レベル: 300 - Advanced
セッションタイプ: Builders' session
トラック: Identity and Access Management
関連エリア: Zero Trust

Ready to break free from the distributed monolith? In this session, build production-ready patterns for implementing comprehensive Zero Trust controls from application entry points through to your service mesh. You'll create a secure service architecture using Amazon VPC Lattice and Amazon IAM, then implement differentiated access controls: API Gateway for customer-facing services and Amazon Verified Access for employee applications, where access decisions incorporate user context, device posture, and behavioral signals. Working with provided templates, you'll decompose a shared environment into properly isolated services, implement fine-grained authorization using Amazon Verified Permissions, and establish secure service-to-service communication patterns. You must bring your laptop to participate.

スピーカー:

• Steve Lynch, Principal Security SA, AWS
• Alex Waddell, Sr. GTM Security Specialist SA UKI, Amazon Web Services
• Otto Kruse, Principal Solutions Developer, Amazon Web Services
• Owen Hawkins, Principal Solutions Architect, AWS

会場の雰囲気

Pennsylvania Convention Centerの4階、Terrace Ballroom Content Hub内のBuilders' Session 2会場で開催されました。Builders' sessionということで、参加者は全員ラップトップを持参し、実際に手を動かしながら学ぶスタイルでした。

会場には約40名ほどの参加者がいました。私にとっては初めてのBuilders' session参加でギリギリ到着だったのもあってめちゃくちゃ緊張しました。 英語をかろうじて聞き取って、AWSの構成図を見て何をやっているか理解してやっと安心しました。講師の方々が各テーブルを回って質問に答えてくれるなど、とても充実した環境でした。

セッション内容

Before: 分散モノリスの問題点

ワークショップは、「分散モノリス」の問題を抱えたアーキテクチャから始まりました。 「分散モノリス」は技術的な実装（複数のサービス、データベースなど）においてマイクロサービスに似ているものの、サービス間の密結合によりモノリスのように動作するシステムを指します。

モノリスからマイクロサービスへ移行する際に、技術的な分離だけ行って、サービス間の依存関係をきちんと切り離さなかった結果として生まれることが多いそうです。

図: 一見マイクロサービスに見えるが...

このアーキテクチャでは、以下のような問題がありました。

1. 過剰に広い権限
   • 各Lambda関数のIAMロールに、他のすべてのサービスを呼び出すための権限が付与されている
   • 最小権限の原則に反している
   • セキュリティ侵害時の影響範囲が大きい
2. Lambda関数の直接呼び出し
   • OrderサービスのLambda関数が、InventoryサービスやPaymentサービスのLambda関数を直接呼び出している
   • 同期的な呼び出しによるコストの増大（呼び出し元の関数も実行中のまま待機）
   • エラーハンドリングの複雑化
3. 認証・認可の不統一
   • サービスごとに異なる認証メカニズム
   • APIレベルでの粗い認可しかできない

本セッションでは上記の問題に対して、順番に対応していきます。

きめ細かな承認を確立する

このワークショップの最初の課題は、アプリケーション全体できめ細かな承認を確立することでAmazon Verified Permissionsを使って解決していきます。

Amazon Verified Permissionsの特徴

• Cedar言語を使った柔軟な権限制御
• ユーザーの身元を考慮してリアルタイムで評価できる
• Cognitoのユーザーグループとの連携

Amazon Verified PermissionsはCedar言語を使って権限を制御します。Cognitoのユーザーグループと、このきめ細かな承認を確立するグループと紐付けして権限を適用するイメージとなります。

今回は2グループを使って権限の適用を確認しました。

• RegularCustomers（通常の顧客）
• BannedCustomers（制限されたユーザー）

ポリシーの例（RegularCustomers）

permit (
    principal in
        SharedAPIGateway::UserGroup::"us-east-1_FNC4P6n0M|RegularCustomers",
    action in
        [SharedAPIGateway::Action::"get /inventory/products",
         SharedAPIGateway::Action::"get /inventory/products/{id}",
         SharedAPIGateway::Action::"get /inventory/products/{id}/stock",
         SharedAPIGateway::Action::"get /users",
         SharedAPIGateway::Action::"get /users/{user_id}",
         SharedAPIGateway::Action::"post /users",
         SharedAPIGateway::Action::"put /inventory/products/{id}/stock",
         SharedAPIGateway::Action::"put /users/{user_id}"],
    resource
  );

ほぼ全てのAPIを使用可能です。

ポリシーの例（BannedCustomers）

permit(
  principal in SharedAPIGateway::UserGroup::"us-east-1_FNC4P6n0M|BannedCustomers",
  action in [ SharedAPIGateway::Action::"get /users" ],
  resource
  );

一方でBANされたユーザーはユーザー一覧しかアクセスできないようにしています。
ワークショップではそれぞれのユーザーでアクセスして、BannedCustomersはどのAPIもコールできないことを確認しました。

SPA + バックエンドの構成なので、BANされたユーザーはSPAでAPIが呼び出せずエラーが表示されるような形となります。

Lambda オーソライザーで権限チェックロジックを実装する必要などなく、Amazon Verified Permissionsを使うことで、権限ポリシーをコードから完全に外部化し、動的に管理できる構成となります。

このようなやり方でユーザーのアクセス権限を制御することができるんだと大変勉強になりました。

独立したサービスに分解する

2つ目の課題は、密結合した分散モノリスを、本当に独立したサービスに分解することでした。
現在はLambda関数からLambda関数を直接呼び出しています。

そこを本アーキテクチャではVPC Latticeアーキテクチャを使用して解決します。

VPC Latticeを使ったアーキテクチャ

図: VPC Latticeを使用したサービス間通信 - 各サービスが独立したVPCに配置される

今までは同じVPC内で直接呼び出していたLambda関数を、Proxy Lambdaを先頭に構えて各LambdaとはVPC Latticeを経由してアクセスする形となります。

VPC Lattice を使用すると、サービスを隔離された VPC に配置し、安全なエンドポイントを介してアクセスを制御できるため、アーキテクチャが変革されます。各サービスとのやり取りはこれらのエンドポイントを通過するため、IAM 認証が強制され、包括的なアクセスログが記録されます。

サービス間のすべての呼び出しは、適切なIAMベースの認証を使用してVPC Lattice経由でルーティングされます。（今回のハンズオンではワークショップのプロビジョニングを簡素化するためにIAM認証を使用していなそうですが、一般的には使用する想定と書いてありました）

今回のハンズオンでは、すでに全て作成されていたのでAPI GatewayでInvokeするLambda関数をInventoryの関数名からProxyのLambda関数に変更してサービス間通信を実現する形となります。

この状態で再度画面を触ると特にアプリケーション自体の挙動が変わらず、VPC Lattice経由での通信となっていることを各種ログなどから確認可能でした。

私はLambda間を直接Invokeするのは避けてSQSなどで連携は考えたことがありましたが、VPC Latticeを使ってLambda間および他サービス連携が可能になるケースもあるなぁと勉強になりました。

管理者アクセスの差別化制御（Amazon Verified Access）

3つ目のステップとして、従業員向け管理アプリケーションへのアクセス制御についても説明がありました。実際のハンズオンでは時間の関係で実装はしませんでしたが、こんな風に改善できるよという説明がありました。

図: 管理者ダッシュボード - 全データベースに直接アクセスしている問題のあるアーキテクチャ

現状の管理者ダッシュボードは、全サービスのデータベースに直接アクセスしているという大きな問題があります。これをAmazon Verified Accessを使って改善するアプローチが紹介されました。

従来のVPNベースのアクセスでは、一度ネットワークに入ってしまえば内部のリソースに自由にアクセスできてしまいます。Amazon Verified Accessを使うことで、アクセスのたびにユーザーの身元、デバイスの状態、アクセスパターンなどを継続的に検証し、より安全なアクセス制御が実現できるとのことでした。
ここはふわっとした理解なので実際に触ってみてキャッチアップしてブログに書いていきたいですね。

まとめ

本ワークショップでは「きめ細かな承認を確立する」と「独立したサービスに分解する」という2つの主要な課題に取り組みました。特に印象的だったのは、VPC Lattice、Verified Permissionsという2つのサービスを組み合わせることで、システムの分散や、安全なアクセス制御、きめ細かい認可制御を実装できるといった知見を得ました。

Lambda関数ごとに処理が密結合しているケースやユーザーグループの権限管理について課題を感じた際は改めて本セッションの内容を振り返ってみたいかつ、使い勝手を評価できればと思いました！

最後までご覧いただきありがとうございましたー！！