re:Invent 2024: FISとGrosvenorが語るCedar Policyによる認可実装
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Customer insights on application authorization (SEC346)
この動画では、アプリケーションにおける認可の実装について、FIS ProphetとGrosvenor Engineering Groupの2つの事例を通じて解説しています。Cedar Policy言語とAmazon Verified Permissionsを活用した認可の実装方法が具体的に示され、特にRole-Based Access Control (RBAC)とAttribute-Based Access Control (ABAC)を組み合わせた柔軟な権限管理の実現方法が詳しく解説されています。FISの事例では保険数理モデリングプラットフォームでの認可実装を、Grosvenorの事例では予算3,000ドル以下の作業を現場で即時承認できる仕組みなど、実践的なユースケースが紹介されています。また、Amazon CognitoのEssentials SKUの新機能と、それがAmazon Verified Permissionsとどのように連携するかについても説明されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Policy-based authorizationの概要と本セッションの構成
みなさん、こんにちは。re:inventを有意義に、そして楽しくお過ごしのことと思います。4日目までご参加いただき、ありがとうございます。これから1時間、アプリケーションにおける認可について話をさせていただきます。本日は、AWSのテクノロジーを使って、アプリケーション内でユーザー認可を実装した事例について、2社のAWSカスタマーからお話を伺います。私はCedar Policy言語とAmazon Verified PermissionsサービスのプリンシパルプロダクトマネージャーのJulian Lovelockです。本日は、Grosvenor Engineering GroupのCon TsalikisとFidelity Information ServicesのAna Kosuticにもご登壇いただきますが、お二人の自己紹介は登壇時にお願いしたいと思います。
まず、Policy-based authorizationとは何か、なぜそれが必要なのかについて説明します。次にCedar policy言語とAmazon Verified Permissionsについて紹介し、その位置づけを説明します。その後、Fidelity Information Services（FIS）とGrosvenor Engineering Groupの2つのケーススタディに深く踏み込んでいきます。そして最後に、いつものように結論と次のステップについてまとめたいと思います。
認可の課題とCedar Policy言語の導入
ほとんどの組織では、数百、あるいは数千のアプリケーションが存在し、これらのアプリケーションを通じて、顧客や従業員、パートナーが企業のリソースにアクセスしています。これらのリソースには、データや機能、さらには物理的なスペースも含まれます。 通常、各アプリケーションは独自の権限管理を行い、独自の認可判断を下しています。 これにより、監査の観点からいくつかの課題が生じています。組織全体で顧客やユーザーがどのようなリソースにアクセスできるかを監査するのにコストがかかるという問題があります。金融サービスなどの規制環境では、誰が何にアクセスできるかを監査人に説明するプロセスにかなりの費用がかかります。また、各アプリケーションが独自の権限システムを実装し、各開発チームがユーザー権限の実装方法を一から考え直すため、リスク要素も存在します。さらに、新しいアプリケーションを構築するたびに権限システムを再作成する必要があるため、摩擦も生じています。
これは新しい問題ではありません。実は、認証の分野ではすでにこの問題を経験し、解決してきました。少し昔を振り返ってみると、各アプリケーションが独自にユーザーを管理し、独自の認証を行っていた時代がありました。それは同様の問題を引き起こしていましたが、 Identity Providerと呼ばれる中央集権的な認証プロセスを導入することで解決しました。 この解決を可能にした要因の一つが、OIDCやSAMLなどの標準化されたプロトコルの使用でした。これによってアプリケーションがIdentity Providerと通信できるようになりました。
現在、私たちは認可についても同様のアプローチを取っています。 認可プロセスを中央のポリシーおよび決定エンジンに集約しているのです。このポリシーと決定エンジン、つまり認可サービスは、 アプリケーション内でユーザーが実行を許可されている操作を記述したポリシーのセットを保存します。 ユーザーがアプリケーションを使用して何かを実行しようとするたびに、認可サービスを呼び出し、それが許可されているかどうかをポリシーに基づいてチェックします。 また、これらのアプリケーションは自身で権限を管理する必要もあります。ユーザーがアプリケーションを使用する中で権限は変更されます - 新しいロールを作成したり、権限を割り当てたり、アクセスを許可したりします。そのため、アプリケーションはユーザーの使用に応じて動的に権限を変更できるように、ポリシー管理APIも必要とします。
これらすべてを実現するためには、ポリシー言語が必要です。誰が何をする権限を持つのかというルールを明確に表現するための言語が必要なのです。ここでCedarの出番となります。Cedarは、AWSが開発したポリシー言語で、約1年半前にオープンソース化されました。これにより、Amazon Verified Permissionsを使用しているかどうかに関係なく、誰でもCedarポリシー言語を活用して、1つまたは複数のアプリケーション内で誰が何を許可されるかを記述できるようになりました。私たちは言語仕様だけでなく、ポリシーを評価して判断を下すDecision Engineもオープンソース化しました。
この言語を設計する際の主要な基準の1つが読みやすさでした。開発者でない人でもポリシーを見て、何が行われているのかを理解できるようにしたかったのです。 このポリシーは比較的シンプルです。Doctorと呼ばれるロールを認識し、そのロールを持つPrincipal（ユーザーとも呼ばれます）が、Patientタイプのリソースに対して、患者の紹介や患者記録の更新といった2つのアクションを実行することを許可しています。ただし、ここには条件があります。 その条件とは、医師がその患者のプライマリケア医である必要があるということです。ここでは、RBAC（Role Based Access Control）とABAC（Attribute Based Access Control）の両方を、1つの比較的読みやすいポリシーステートメントに組み合わせていることがお分かりいただけると思います。
Amazon Verified Permissionsの実装例
では、これがアプリケーションでどのように機能するのでしょうか？これを活用するためのアプリケーションの異なる構成要素とは何でしょうか？ScotとAnaがまもなく説明するFidelityのアプリケーションProphetを例に取ると、実際には3つのコンポーネントがあることが分かります。 ここでの課題は、ユーザーがWorkspaceというリソースに対して「編集」というアクションを実行しようとしているということです。 アプリケーション内で最初に行うべきことは、そのリソースに関する情報を収集することです。そのため、リソースデータベースからリソースに関連する属性を取得します。同様に、ユーザーに関する情報も収集する必要があります。 その後、これらの情報をAmazon Verified Permissionsに提供し、「これらのグループに属し、これらの属性値を持つユーザーが、これらの属性値を持つWorkspaceにアクセスしようとしています。これは許可されますか？」という問い合わせを行います。Amazon Verified Permissionsは判断を返し、その判断を実施するのはアプリケーションの役割となります。
ここでいくつかの専門用語を紹介しました。上部にあるのは、Policy Information Point（ポリシー情報ポイント）と呼ばれることが多いもので、ここではポリシーの適用に関連する情報を収集します。次にPolicy Decision Point（ポリシー決定ポイント）があり、ここでアクセスを許可するかどうかの判断を行います。そして、Policy Enforcement Point（ポリシー実施ポイント）がその判断を実施します。 XACMLに詳しい方は、これらの用語をご存じでしょう。
FIS ProphetにおけるAmazon Verified Permissionsの活用
以上で私の説明は終わりです。ここでScotをステージにお招きしたいと思います。彼がProphetアプリケーションを紹介し、その後Anaがデモンストレーションを行います。ありがとうございました、Julian。皆さん、こんにちは。私はScot Glasfordです。後ほどライブデモを行うAnaと一緒に登壇しています。まず、私の経歴を少しご紹介させていただきます。私は保険業界で15年の経験を持つアクチュアリーで、FISで金融モデリング技術と規制報告の分野で仕事をする機会に恵まれています。北米において、規制ライブラリが適切なコードに従い、保険業界の変化する規制環境のトレンドに対応していることを確認する取り組みを主導しています。私の役割の一つは、クライアント管理やクライアントとの関係構築を含め、クライアントからのフィードバックが製品に反映されることを確実にすることです。
FISについてご存知ない方もいらっしゃるかもしれません。FISについてご紹介させていただきます。私たちは金融サービスのソフトウェアソリューションを提供する企業で、金融サービスのライフサイクル全般にわたるソリューションを展開しています。FISの規模感をお伝えしますと、世界中に70,000人の従業員を抱え、昨年だけでもFISのソリューションを通じて50兆ドル相当の決済が処理されました。ただ、今日は銀行業務についてお話しするのではなく、私たちのソリューションでAmazon Verified Permissionsをどのように活用しているかについてお話しします。そこで重要になってくるのがFIS Prophetです。FIS Prophetは保険数理モデリングプラットフォームで、非常に成功を収めているプラットフォームです。世界のトップ50の保険会社の80%が何らかの形でFIS Prophetを利用しています。70カ国に及ぶ世界中で10,000人のユーザーを持つ大規模なフットプリントを有し、Prophetは35年の歴史を誇ります。これほどの成功を収めた理由は、その優れた柔軟性にあります。
また、計算を効率的にスケールできることで、今日の規制要件にも十分に対応しています。Prophetのユーザーの使用例をご紹介させていただきます。多くの組織がProphetを導入する主な理由の一つは、規制要件を満たすためです。私は過去数年間、米国の規制報告であるLDT Iのソリューション開発に携わってきました。また、世界中の財務報告に対応するIFRS 17のソリューションも提供しています。さらに、世界中の資本報告にも対応しており、これには欧州のSolvency Two、米国のRBC、Bermudanの資本要件などが含まれます。
Prophetの魅力的な特徴の一つは、ユーザーが独自のモデルをコーディングできる点です。これにより、クライアントは実質的に独自のIPを開発し、価格設定の際に新しいタイプの契約や契約機能をテストする機会を得ることができます。また、ユーザーはProphetを使用して資本管理や資産負債管理を行うこともできます。これらのフレームワークにより、組織は再保険戦略や資産戦略を策定し、資本市場でのポジショニングを行うことができ、経営陣は収益性を高めるための意思決定を行うことができます。
Prophetは35年の歴史がありますが、では、これからの35年をどのように生き残っていくのでしょうか？私たちはProphetをクラウドに移行し、AWSを基盤としたSaaSソリューションをクライアントに提供しています。昨年リリースした新しいモジュールの2つが、Risk Production ManagerとClimate Risk Financial Modelerです。Risk Production Managerは、保険数理担当者のクラウドリソースへのアクセス方法を革新的に変えるものです。もはや保険数理担当者は、計算グリッドをスケールアップするためにIT部門の介入や専用環境を必要としません。ユーザーは自分のローカルマシンでモデルやワークスペースを開発し、クラウドにアップロードして、モデル実行を高速化するために必要なクラウドリソースを利用することができます。
場合によっては、1日以上かかっていたモデルの実行時間が1時間未満に短縮されることもあります。これは単にクラウドコンピューティングリソースを利用できるようになったからです。FISがSaaSで価値を見出しているのは、クライアントの保険業務を中断することなく、ツールを迅速かつ効率的に展開できることです。また、気候リスクのような新たなリスクにも迅速かつ効率的に対応できます。Climate Risk Financial Modelerを使用すると、保険会社は世界中の物理的資産に対するリスクを定量化することができます。気象パターンや温室効果ガス排出シナリオをモデル化し、世界中の潜在的な損失を定量化することができます。
このプラットフォームでは、非常に優れたダッシュボードを見ることができます。地球の画像や、エクスポージャーの所在を定量化・可視化する円が表示されます。このダッシュボードを見ると、例えば大きな緑の点で示されているUKに大きなエクスポージャーがあることが一目で分かり、これは風害や雹害などが原因かもしれません。アクチュアリーやリスクマネージャーがこれらのレポートを確認し共有する際、結果を素早く理解し、組織全体で共有するのに非常に便利な方法となっています。
さて、これがProphetの進化の一例ですが、もう一つの進化として、Amazon Verified Permissions を組み込んだことで、アクチュアリーがコンプライアンス規制に対応できるようになりました。FIS Prophetの重要な理念の一つは規制への準拠です。今日お話ししたい規制は、Sarbanes-Oxley（SOX）についてです。SOXは、公開市場の投資家や規制当局が利用する財務報告の完全性を確保するために制定された米国の法律です。SOXは財務報告の完全性の維持を要求しており、これは運用面で課題となります。なぜなら、モデルやデータへのアクセスに関するルールや規制を設ける必要があるからです。Sarbanes-Oxleyの下では、財務プロセスのすべての部分が監査可能でなければならず、誰が何にアクセスしたのか、いつアクセスしたのか、データがいつ作成されたのかを追跡できる必要があります。SaaSプラットフォームを使用しない場合、アクチュアリーにとってのもう一つの課題は、財務報告に関わる複数のシステムの存在です。
これらのシステムが分散していると、Sarbanes-Oxleyコンプライアンスのために、異なるシステムの認証システム管理が課題となります。また、アクチュアリーにとってのもう一つの課題は、組織の異なる部門で財務報告の一部を作成する大規模なアクチュアリーチームを管理し、それらを集約する必要があることです。このようなシナリオでは、認証の中央管理が重要な価値を持ちます。
職務分掌に関して、Sarbanes-Oxleyは特定の役割の区別を要求します：モデラーのみがモデルを実行でき、モデル承認者はレビューはできますがモデルを実行することはできず、監査人は結果を確認できますがモデルに直接関与してはいけません。このような分離を容易にする認証フレームワークがあることは、アクチュアリーにとって特に魅力的です。
では、FIS Prophetでこれをどのように実装したのかをお話しします。 ここでの主な変更点は、Workspaceに個別の属性をタグ付けできるようになったことです。Workspaceには無限の属性を付けることができますが、例えば、あるモデルをイタリアのモデル、Q2レポート用、生命保険契約専用としてタグ付けすることができます。これを従来のモデラー、監査人、レビュアーなどのユーザーロールと組み合わせることで、堅牢な認証フレームワークが構築され、アクセス権限を正確にコントロールできるようになり、Sarbanes-Oxleyコンプライアンスの遵守に大きく貢献します。
ProphetアプリケーションでのAmazon Verified Permissionsのデモンストレーション
Prophetについて私からは以上です。では、Prophetでの実装について説明するために、Anaにバトンを渡したいと思います。ありがとうございます、Scott。まず、画面を切り替えさせていただきます。皆様、こんにちは。FISのソフトウェアエンジニアのAna Kosicです。AWSチームと協力して、パーミッションフレームワークの実装とAmazon Verified PermissionsのProphetプラットフォームへの統合に取り組んできました。本日は、実際のアプリケーションでこれらの多くをデモンストレーションし、パーミッション管理に焦点を当てて説明させていただきます。
まずは、標準的なProphetのテストユーザー（通常はアクチュアリー）としてログインして、ユーザーの視点からどのように機能するかをお見せしましょう。Production Managerアプリケーションを開いて、Workspacesページにアクセスしてみましょう。最初に、Workspaceとは何かを説明させていただきます。Workspaceは、Prophetプラットフォームの基本的な概念で、ユーザーがモデル実行を通じて計算を実行できる環境を提供します。これは、アクチュアリー分析に必要な最終結果を生成し、計算を実行するのに役立つ様々なメタデータで構成されています。
Workspaceは私たちのプラットフォームにとって重要なため、パーミッションの仕組みを説明するために選びました。画面には、Global WorkspaceとEuropean Workspaceという2つのオブジェクトがあります。Global Workspaceを開くと、構造、実行設定、製品、ローカルテーブルセットなど、先ほど言及したすべてのメタデータが表示されます。では、計算を実行する前に、名前や説明を編集するなど、いくつかのメタデータを編集して、Workspaceオブジェクトに対する編集アクションをデモンストレーションしてみましょう。
簡単に説明を編集して保存してみましょう。予想通り、Workspaceが保存されたという成功レスポンスが返ってきました。次に、European Workspaceを試してみましょう。European Workspaceという名前ですが、説明を見るとイタリアでのみ使用可能とあり、追加の制限があることを示唆しています。説明をイタリアとスペインで使用可能と編集してみましょう。すると、このWorkspaceを更新する権限がないというエラーが表示されました。
ここで新しいブラウザに切り替えて、管理者ユーザーとしてログインし、追加機能を紹介するとともに、なぜアクチュアリーユーザーが一方のWorkspaceを編集できて、もう一方を編集できなかったのかを説明したいと思います。ブラウザ間の視覚的な区別を明確にするために、ライトテーマに切り替えましょう。管理者ユーザーとして、Platform Administratorという追加のアプリケーションにアクセスできます。これにより、ユーザー、属性、ロールのページが提供されます。ロールのリストを見ると、Workspace EditorロールとWorkspace Administratorロールがあります。Workspace Editorロールは、Workspaceオブジェクトの作成権限なしで、表示と変更の権限を与えます。デモでは、Production Managerアプリケーションに焦点を当てて、Workspaceオブジェクトの表示と変更の権限について見ていきます。
アプリケーションの左側には、Workspace、Table Set、Jobなどの利用可能なオブジェクト（リソースと同義）のリストが表示されています。上部には、これらのオブジェクトに対して許可できるアクションのリストが表示されています。このロールでは、Workspaceオブジェクトに対してのみ、作成以外のすべてのアクションを許可することにしました。一方、Workspace Administratorロールでは、Workspaceの管理とすべてのアクションの実行に関するフルアクセスが与えられており、同じくWorkspaceオブジェクトに対してのみ、すべてのアクションを選択しています。
ロールを使用する際のバックグラウンドでの動作について説明させていただきます。新しいロールを作成すると、実際には新しいCedarポリシーが作成され、Amazon Verified Permissions（AVP）に保存されます。 AWSコンソールでご覧いただきましょう。Amazon Verified Permissionsを開くと、利用可能なポリシーストアのリストが表示されます。各ポリシーストアは一度に1つのテナントにのみ専用となっており、2番目のストアはこのデモで使用しているテナントにのみ専用となっています。 先ほど申し上げたように、2つのポリシーがあります。1つ目はWorkspace Editor用 、2つ目はWorkspace Administratorロール用です。これらのポリシーについては、この後Julianが詳しく説明します。
ロールに話を戻しましょう。ロールは、コースグレインレベルでユーザーに権限を割り当てる機能を提供します。しかし、より細かい粒度の権限を割り当てられるようにしたいと考え、そのためにこのページを用意しました。ここでは、カスタム属性を定義し、Attribute-Based Access Controlを実施することができます。類似の属性をグループ化 することができ、そのためここではCountryという属性グループがあり、特定の国を定義する属性が含まれています。 属性を使用して、ユーザーとオブジェクトの両方にタグ付けができます。ここでは、Italy、Spain、Serbia、Hungary、USAという属性があります。最初にALLがあることに気付くと思いますが、これはグループ内のすべての属性を表す特別な属性で、すべてのグループが持っています。この場合、ALL属性はすべての国を表しています。これは、管理者ユーザーが個々の属性を一つずつリストアップする代わりに、すべての属性をオブジェクトやユーザーに一括で割り当てたい特別なケースで非常に便利です。
2人のユーザーがいます。現在表示しているadminユーザーと、最初のブラウザからのactuaryユーザーです。adminユーザーにはWorkspace Administratorロールが割り当てられており、これは オブジェクトに対して実行できるアクションを定義する場所です。また、すべての国を表すALL属性でタグ付けされています。つまり、adminユーザーは、任意の国でタグ付けされたWorkspaceに対して、Workspace Administratorロール内で定義されたすべてのアクションを実行できます。一方、actuaryユーザーにはWorkspace Editorが割り当てられ、さらにSpain属性のみでタグ付けされています。これは、actuaryユーザーがSpainでタグ付けされたWorkspaceに対して、Workspace Editor内で定義されたアクションを実行できることを意味します。
ここで、Production Managerアプリケーション を管理者の視点から再度開きたいと思います。管理者ユーザーは、オブジェクトに割り当てられた属性のリストを確認することができるためです。 まずGlobal Workspaceを見てみましょう。Global WorkspaceはすべてのCountryを表すALL属性でタグ付けされており、これがactuaryユーザーがこのGlobal Workspaceで編集を実行できた理由です。別のWorkspace、European Workspaceを見てみましょう。 このEuropean WorkspaceはItalyでタグ付けされています。先ほど説明したように、actuaryユーザーはSpainでタグ付けされており、ItalyとSpainは一致しません。これは重要なポイントです：オブジェクトに割り当てられた属性のリストとユーザーに割り当てられた属性のリストの交差部分が、ロール内で定義されたアクションをユーザーが実行できるかどうかを決定します。
この例では、オブジェクト側にItalyがあり、ユーザー側にSpainがあり、ItalyとSpainが一致していないため、属性リストの交差がありません。そのため、追加ユーザーはこのEuropeanワークスペースでの編集が拒否されていました。しかし、管理者ユーザーとして属性を操作できるので、もう1つの属性であるSpainを追加しましょう。これでオブジェクト側とユーザー側の両方にSpainが存在することになり、このEuropeanワークスペースでの編集が可能になるはずです。
最初のブラウザに戻って、ユーザーがログインしている状態で、この変更が正しく反映されているかを確認してみましょう。今度はユーザーがこのEuropeanワークスペースで編集を実行できるようになりました。試しに説明を編集して、「このワークスペースは現在ItalyとSpainで使用可能です」と入力してみましょう。「ワークスペースが保存されました」という期待通りの成功レスポンスが表示されました。これは、私たちのシステムがRole-Based Access ControlとAttribute-Based Access Controlをどのように採用しているかを実際に示すものです。
Amazon Verified PermissionsとProphetプラットフォームの統合に携わった開発者として、この選択の背景にある理由をいくつか共有したいと思います。私たちはセキュリティを提供しており、管理とトラッキングが容易なアクセス制御を実現したいと考えていました。Amazon Verified Permissionsは、そのポリシー言語により、外部からパーミッションを定義し、これらのポリシーを一元的に管理することを可能にします。実行されたすべてのアクション、誰が実行したか、いつ実行されたかを記録し、これらの記録を安全にレビュー用に保存することで、明確な監査証跡を提供します。また、各テナントに専用のポリシーストアを持つことで、クライアントデータを分離し、マルチテナンシーを容易にサポートできることも大きな利点です。
Amazon Verified Permissionsとの統合は簡単です。ユーザーがオブジェクトに対してアクションを実行することを許可するか拒否するかに応じて、明確なAllowまたはDenyレスポンスを返す1つの認可APIコールがありました。今回のデモでは、ワークスペースに対する編集アクションの認可コールでした。これらすべてがパーミッション管理を簡素化しただけでなく、柔軟性とセキュリティを向上させ、アプリケーションにとって重要な資産となりました。本日のイベントでこれらを共有させていただき、ありがとうございました。質問や話し合いたいことがありましたら、私はこの場にいますので、Julianに引き継ぎたいと思います。
では、スライドに戻りましょう。ポリシーについて詳しく説明し、Anaが作成したポリシーが実際にどのように機能するかをお見せしたいと思います。ポリシーのスコープでは、この場合、Workspace Editorというロールを指定しています。そして、Anaが管理コンソールで実際にWorkspace Editorというロールを作成し、このポリシーを適用したことを覚えているでしょう。彼女はWorkspace Editorに許可される異なるアクション（読み取り、ダウンロード、編集は可能だが作成は不可）を選択しました。ポリシーのスコープ内で、これらの特定のアクションが表現されているのがわかります。もしAnaが作成のチェックボックスにチェックを入れて保存した場合、このポリシーは更新され、このロールに対する許可されたアクションとして作成が含まれることになります。
また、属性の交差についての問題もあります。 ポリシーのベース部分には、属性ベースの条件のセットがあることがわかります。これらを見ていくと、ユーザーが全ての国に対してタグ付けされている場合は問題なく、条件は満たされます。あるいは、Workspaceが「全て」とタグ付けされている場合も、同様に条件は満たされます。 しかし、どちらでもない場合は、ユーザーの属性がWorkspaceの属性に一致している必要があります。これがAnaがデモで示したことです - 彼女はWorkspaceにSpainという属性を追加し、それによってSpainのタグを持つユーザーがそのWorkspaceを編集できるようになりました。このように、ポリシーがRole-Based Access ControlとAttribute-Based Access Controlを組み合わせて、適切に権限の範囲を絞り込んでいることがわかります。
Grosvenor Engineering GroupにおけるAmazon Verified Permissionsの実装
ここで、Conに引き継ぎたいと思います。Conが Grosvenor Engineeringについて紹介してくれます。ありがとう、Julian。皆さん、こんにちは。ここに参加できて嬉しく思います。私はCon Tsalikisで、Grosvenor Engineering GroupのChief Technology Officerを務めています。
今年のre:inventでここLas Vegasで私たちのストーリーを共有できることを大変嬉しく思います。Grosvenor Engineering GroupはSydneyを拠点とするオーストラリアの企業です。 私たちの事業は、オーストラリアとニュージーランド全域のHVAC、消防、電気システムなどのビルの技術システムを管理することです。これには、オペラハウス周辺から砂漠地帯まで、あらゆる高層ビルが含まれます。私たちのミッションは、予防的なメンテナンスアプローチを用いて、不動産所有者のために持続可能な成果を提供することです。
このミッションを達成するために、私たちは早い段階で、メンテナンス管理機能を組み込んだ独自のEnterprise Resource Planningシステムを構築する必要があることを認識しました。90年代後半には、私たちのAsset Resource Management System（ARMS）を開発し、これまでに160万以上の資産に対して1,700万以上のActionable Insightを解決してきました。Actionable Insightという概念について説明すると、これらは長年かけて設計・進化させてきた保守計画と、ビルのシステムから抽出した洞察を技術者にフィードバックすることから生まれています。技術者が現場に行くと、保守作業や修理作業で何をすべきかを理解できます。ARMSは、車をメカニックに持って行って、車を効率的に走らせ、長持ちさせるために必要なことを全て確認するようなものだと考えてください。
ご想像の通り、これほど複雑な資産と運用を扱うため、システムの近代化を進めるにあたって、堅牢な認可システムが強く求められました。 将来の認可システムについて話す上で、ARMSの進化について説明するのが良いでしょう。現在のARMSは、実質的に2つのバージョンを持つ内部ツールでした。1つは、現場でリソースを調整するための従来の機能を備えたバックオフィスバージョンです。もう一方は、技術者が現場で作業を行うためのフィールドサービス機能です。この検証の循環的なワークフローを通じて、私たちは情報を文脈化し、顧客向けのポータルを通じてより詳細な財務的コンテキストを提供することができます。これにより、顧客は複雑な意思決定を行い、メンテナンスと資産のパフォーマンスを理解し、一般的に建物をより深く理解することができます。
ARMSの将来像について、これは私たちのコアビジネスの成長に起因するものですが、サービス提供に貢献するパートナーとしての下請け業者が急増しています。次のステップとして、このマルチテナント機能を強化し、ARMSを外部ツールとして活用することで、より詳細なサービス提供を実現していきます。この詳細化により、お客様により充実したサービス管理機能、より深い資産パフォーマンスの洞察、そしてビルディングシステムからのより多くのIoTデータを提供することで、より良いユーザー体験を実現します。
これらすべてを実現するため、そしてレガシーな一枚岩システムからAWSでホストされるクラウドベースのWebアプリケーションへの移行について考えると、どのコンポーネントを再設計して分離する必要があるのかを理解する必要がありました。Authorizationは重要なコンポーネントでした。なぜなら、ビジネスロジックの異なる層に紐づく様々なペルソナが存在し、それぞれのユーザーに適した表示をカスタマイズするためにデータ階層の分離が重要だったからです。例えば、現場の技術者というペルソナの場合、特定のビルディングや特定の資産にアクセスする必要があり、それは彼らに求められる成果を達成するために必要なものです。
これをより理解しやすくするために、ARMSアプリケーションの実例を見ていきましょう。実際の課題を確認した後、その結果を達成するために必要だったすべてのコンポーネントについて、順を追って説明していきます。まずここでARMSのバックオフィス版を見ていただきますが、私自身を技術者として作業に割り当ててみましょう。具体的にはこれはWork Orderです。自分をその作業に割り当てて、その作業のProject Configurationに移動すると、そのペルソナのワークフローのビジネスロジックを定義する様々な属性が表示されます。ここで現場の技術者をシミュレーションして、ご覧いただいているmyARMSアプリケーションに移動し、ワークフローとAdditional Work セクションに進むと、先ほどのProject Configurationと同様に、1,800ドルという見積額が表示されます。
これは、技術者が現場で承認なしに実行できる作業の制限額とバジェットを設定するものです。資産を選択し、コアタイトルと作業理由をテスト用に入力すると、見積もりの様々なコスト要素を入力するオプションが表示されます。時給95ドルで20時間を入力すると、計算された合計額が1,900ドルとなり、先ほど設定したプロジェクトパラメータの見積もりバジェットを超過することになります。これは、技術者が現場で作業にアクセスできず、クライアントからのさらなる承認が必要となることを意味します。
これが私たちが実装したかったワークフローです。Authorization の課題に取り組む際、私たちは一歩引いて、本当に必要なものは何かを理解しようとしました。要件を3つの主要な課題に絞り込みました。最初の課題は、すでに構築されているものを求めていたことです。独自システムのメンテナンスの負担を軽減し、それに伴うセキュリティのオーバーヘッドを抽象化したいと考えていました。また、将来性があり機能が豊富なものを求めていました。なぜなら、製品がどのように進化するかを予測することは難しく、将来のロードマップでの障害となるようなカスタマイズされたソリューションの構築は避けたかったからです。
2つ目の課題は柔軟性についてでした。従来のアプリケーションはRole-Based Access Controls（RBAC）の考え方に基づいて設計されていましたが、先ほどQuick Quotesの属性で示したようなユースケースと同様に、Attribute-Based Access Controls（ABAC）をアプリケーションに組み込みたいと考えていました。アプリケーションが異なるシステムに分散していたため、それらを1つに統合し直す際に、複数のデータストアからポリシーを集約したいと考えていました。認可ロジックを通じてビジネス判断を導くことになるであろう情報を、SQLデータベース、グラフデータベース、あるいはオブジェクトストアに格納されている情報から見つけ出したいと考えていました。
3つ目の課題はスケールについてでした。専用インスタンスを管理する必要がなく、高性能で、できれば水平スケーリングに伴う課題を軽減でき、かつコスト効率の良いサーバーレスなソリューションを求めていました。私たちは2つの異なる選択肢を検討している段階でした。既存のオープンソースソリューションを採用するか、アプリケーションのコード内にカスタムサービスを組み込むかを検討していたのです。そのタイミングでAmazon Verified Permissionsが一般提供を開始しました。アプリケーションの将来的な要件の一部となることが分かっていたテストポリシーをいくつか作成し、Policy Playgroundでテストを行い、その後ポリシーテンプレートを設計してProof of Conceptとしてアーキテクチャに統合しました。結果として、高性能で、予算に合った線形の従量課金モデルを実現することができました。
ここで、レガシーアプリケーションとの統合に採用した2つの異なるアプローチを示すアーキテクチャフローについてご説明したいと思います。1つ目は、AWS SDKを使用した標準的なAPIコールのアプローチです。移行が完了するまでの間、新旧のアプリケーションを並行して実行し、両者で同じ属性を維持したいと考えていました。最初のステップでは、フロントエンドがAmazon Cognitoにログインリクエストを送信し、それによってPre-Authorization Triggerが起動します。このLambda関数は、カスタム属性を収集するか、Cognito User Poolにカスタム属性として注入できる新しい属性を探します。
これらの属性がCognitoに注入されると、認可トークンがフロントエンドに発行され、フロントエンドは任意のAPIコールでこれらの認可ヘッダーをAPI Gatewayに送信します。API GatewayはそのトークンをCustom Authorizerに転送します。Custom Authorizerはトークンを検証し、JWTをデコードしてすべてのカスタム属性を取得します。これらのカスタム属性は、Amazon Verified Permissionsでリクエストに一致するポリシーを探すためのキーとして使用されます。Amazon Verified Permissionsが許可レスポンスを返すと、API Gatewayは適切なLambdaサービスにリクエストを転送するよう指示されます。
2つ目のフローでは、異なる権限を必要とする様々なユーザーに対応するため、Amazon Verified Permissionsを創造的に活用してUIの動作を制御する方法をご紹介します。ユーザーごとに変化する柔軟なユーザーインターフェースを実現したいと考えていました。ここでお見せするのは、アプリケーションの起動時や、実行時の他の設定された間隔やトリガーを通じて、フロントエンドがCognitoにログインリクエストを送信し、Cognitoがフロントエンドにトークンを発行する仕組みです。
そして、フロントエンドは専用のパーミッション用ルートにアクセスします。Custom Authorizerはリクエストをデコードせずに検証しますが、トークンをLambdaサービスに転送します。 Lambdaサービスは属性をデコードし、UI固有のポリシーを検索します。ポリシーからのアクションに基づいて命名規則とカテゴリを持っており、そのユーザーまたは所属グループのUI コンポーネントポリシーがすべてフロントエンドに返され、Web Assemblyストアに保存されてUIの動作を変更します。
これら2つのフローをまとめるために、 それらのポリシーがどのように見えるかをお見せしたいと思います。右側では、JWT属性のサンプルを確認できます。Amazon Verified Permissionsを通じてポリシーを検索するために使用されるカスタム属性がキーと値のペアとして存在します。左上では、UI固有のポリシーを確認できます。ここでは、principleがユーザーまたはグループとなっており、ポリシーの種類を分類するアクションがあり、リソースにはフロントエンドのUIコンポーネントと同じ命名規則に従ったUIコンポーネントポリシー名が設定されています。
左下では、属性ベースのアクセス制御ポリシーを確認できます。これは先ほどお見せしたQuick Forward金額のチャレンジに特化したものです。コンテキストとして$1,000以下のQuick Forward金額が設定されており、リソースにはその判断の基となったProject IDが設定されています。興味深いことに、このProject IDはJWT属性と直接関連付けられていないことがわかります。これはアプリケーションを設計する際に考慮すべき点かもしれません。
次に、ARMSについて再度説明し、 これらのコンポーネントがAmazon Verified Permissionsを通じてどのように適用されるかをお見せしたいと思います。かなり特殊な設定をお見せしています。これはアプリケーション内に存在する固定グループを設定するもので、UI固有のProjectコンポーネントをすべて削除しました。そのため、ナビゲーションメニューのProjectドロップダウンを見ると、Projectオプションが利用できないことがわかります。そして、アプリケーションのRecentセクションに移動して特定のProjectにアクセスしようとすると、Unauthorizedレスポンスが返されます。
Amazon Verified Permissionsでそのユーザーの ポリシーを確認すると、ポリシーが見つからないため、アプリケーションは何も保持していないことがわかります。しかし、 これらの属性をすべて含めて保存すると、Amazon Verified Permissionsに変更が反映されます。適用されたことを確認するためにアプリケーションを更新してみましょう。はい、確認できましたね。ここでドロップダウンを再度確認すると、Projectの要素が表示されており、特定のProjectにアクセスしようとすると、 以前のようにProjectに入ってProject設定タブに移動でき、Quick Quote金額が$1,800に設定されているのが確認できます。
Amazon Verified Permissionsに戻って、そのユーザー向けのUI Component Policyを確認してみると、私自身のケースですが、UI Component Policyが存在していることが分かります。これによって、アプリケーション内のそのエリアへのアクセスが可能になったわけです。次に、Quick Quotesに関するAttribute Based Access Controlsを見てみると、同じポリシースキームが適用されており、そのProject IDに対して800ドル以下という条件が設定されています。ここで、お客様から予算を3,000ドルに増額する承認をいただいたとしましょう。この値を変更して保存すると、Amazon Verified Permissionsに戻ってポリシーを確認できます。同じポリシーが更新され、Quick Amount Contextの値が3,000ドル以下に変更されているのが分かります。
ARMSアプリケーションに戻って、ポリシーを取得する追加作業セクションに移動すると、3,000ドルというポリシーが反映されているのが確認できます。アセットを選択してNextをクリックし、Marinを入力し、テストとテストを入力すると、コスト要素が表示されます。ここでも同様に、レート95で20ドルを入力すると、予算を超過していないことが分かります。Nextをクリックすると、現場でQuoteを実行できることが分かります。お客様のメールアドレス、名前、そして署名を収集し、正常に送信することができます。これにより、承認なしで技術者がその場で作業を開始できる新しいJobが作成されます。
ERPシステムとの実装に加えて、現在取り組んでいる別の課題として、社内で設計されたEnergy Management System（EMS）とERPシステムの統合があります。EMSでは、様々な技術資産や建物から時系列データを収集しています。例えば、エネルギーメーターやコンプレッサー、その他の技術資産からのデータです。これらの時系列データはすべてData Lakeに格納され、Graph Databaseのオントロジーを通じて処理されます。
Data Lakeに保存されているデータとGraph Databaseの相関関係を分析していますが、ここでの課題は、異なるペルソナが異なる情報アクセス権限を必要とする可能性があることです。例えば、ここでお見せしているようなSustainability Officerや、建物全体とそれに関連するすべての資産へのアクセスを必要とするFacility Managerがいるかもしれません。あるいは、21階にいるテナントが、特定のアセットのサブセットにのみアクセスする必要があるかもしれません。このアクセス制限を実現するために、トークンリクエストからネイティブに処理したいと考え、User IDのコンテキストを利用しました。
そして、User IDのコンテキストを通じて、リクエストをVerified Permissionsに転送し、AVPからのAllow/Denyレスポンスに依存するのではなく、リクエストを許可したポリシーの名前を確認します。そのポリシーの命名規則に基づいて、Graph Database内のすべての推論されたエンティティを検索し、関連するすべてのエンティティを見つけます。制限ステートメントを構築します。実際にはもう少し複雑ですが、そのユーザーに関連するアセットを見つけ出し、APIへのレスポンスを構築しています。
それでは、アーキテクチャについてもう少し詳しく説明させていただきます。基本的に、 Lambda AuthorizerがコンテキストをAVPに転送します。リクエストを許可したポリシーの名前を取得し、そのポリシー名を転送します。なお、Graph Databaseには固定の命名規則があります。そこから、関連するすべてのエンティティを見つけ、Data Lakeから関連するすべてのデータを検索します。その後、レスポンスをAPI Gatewayに返送し、そこからは通常通りの処理が行われます。
最後に、Grosvenor Engineering Groupでの経験から得た3つの重要な教訓をお話ししたいと思います。1つ目は、Cedarを自分で作ろうとしないことです。認可ポリシーをコードに組み込むと複雑さが増し、将来のロードマップに制限がかかる可能性があります。2つ目は、Cedarを学ぶことです。Cedarは学習曲線が急な場合がありますが、認可ロジックをアプリケーションコードから分離することで、長期的には大きな効果が得られます。3つ目は、AVPは単なる権限管理以上の機能を持っているということです。先ほどのユースケースでお話ししたように、Verified Permissionsを創造的に活用することで、アプリケーションの動作や機能を豊かにすることができます。
事例から見るAmazon Verified PermissionsとCognitoの相乗効果
ありがとうございました。以上で私からの発表を終わります。Don、お返しします。この2つのプレゼンテーションを通じて見られたいくつかのテーマを取り上げたいと思います。1つは、既存のアプリケーションを新世代バージョンに移行し、その新世代でVerified Permissionsを使用してより細かく安全な認可モデルを実装するということです。両者とも、既存の粗い粒度のRole-Based Modelを取り、それにAttribute-Based条件を追加することで実現しています。つまり、RBACとABACを組み合わせているわけです。特にGrosvenorの例では、認可ルールが実際のビジネスルールとして使用されているのが興味深いところです。Conの例では、Cedarポリシーが支払いのレベルや特定の見積もりの価値を定義していました。これはセキュリティのユースケースではなく、ビジネスルールのユースケースです。
両方のケースで、アプリケーションがポリシーを変更しています。管理者がアプリケーションを使用して権限を変更すると、それらの権限がポリシーの更新に反映されます。そして、AVPはポリシーへのすべての変更を監査ログに記録するため、ポリシーの出所を追跡できます。ポリシーがいつ作成されたのか、誰が作成したのかを理解することができます。最後に、Cognitoについて簡単にお話ししたいと思います。このプレゼンテーションでは認可について多く話してきました。
見てきたように、認可は認証に依存しています。Amazon Cognitoの新しいリリースと機能について強調したいと思います。これらは、Amazon Verified Permissionsとの相乗効果を生み出す機能です。Cognitoの価格モデルの中で、新しいSKUであるEssentials SKUについてお話しします。Essentials SKUでは、よりスムーズなユーザーログイン体験を提供するPasswordless認証に加え、SMSやTOTPなどの強力な認証メカニズムをサポートしています。また、コードレスのUI Brandingやローカライゼーションも追加されました。
以前のCognitoバージョンでは、ログインページはこのような感じだったかもしれません。これも十分機能的で目的は果たせていましたが、この新しいリブランディングモデルでは、 このようなログインページをローコードだけで設定できるようになりました。これなら間違いなくチョコレートを買いたくなりますよね。 最後の機能についてですが、これまでCognitoにも実装されていたものの、より高額なAdvanced Security Featuresティアに隠れていた機能が、今回Essentialsティアで利用できるようになりました。Essentialsティアの料金体系には、10,000 MAUまでの無料枠があり、それを超えると1 MAUあたり0.015ドルとなります。Advanced Securityティアはかなり高額だったので、Access Token Customizationがより手頃な価格帯で利用できるようになったということです。
この認可に関連する部分について説明しましょう。Access Token Customizationでは、その名の通り、 ユーザーの属性情報をアクセストークンに含められるようになります。これで、 Clinical IDやTypeといったカスタム属性をアクセストークンにカスタマイズして含めることができます。これが認可に関連する理由は、Amazon Verified PermissionsのisAuthorizedWithToken APIを呼び出すと、このカスタマイズされたアクセストークンを解析し、これらの属性を取り出して、ポリシーの属性ベースの条件判定に使用できるからです。Cognitoのグループメンバーシップとカスタム属性を組み合わせたポリシーを作成できるため、Role-BasedとAttribute-Basedのアクセスコントロールを組み合わせることができます。
セッションのまとめと今後の学習リソース
まとめとして、私たちは何を学んだでしょうか？認証と認可は別物である - これは皆さんご存知でしたね。それぞれ個別の考慮事項、個別のフロー、そして多くの場合、それらのフローを適切に実現するための個別の製品が必要です。独自の権限管理システムを構築することは、率直に言って良くないアイデアです。スケーリングが難しく、ミスを起こしやすく、アプリケーションやルールが複雑になるにつれて、Amazon Verified Permissionsのようなすぐに使える解決策に任せられるはずのものに、ますます多くの時間を費やすことになってしまいます。
本日は、統合モデルに関する2つの素晴らしい事例を見てきました。アプリケーションがAmazon Verified Permissionsとどのように連携するか、Policy Enforcement Pointはどこにあるのか、Policy Information Pointsはどこにあるのか、そして情報をどこで収集し、Amazon Verified Permissionsを呼び出して、決定を得て、それを実施するのかについて見てきました。両方のケースで、Constrained Rolesパターンと呼ばれるパターンに従いました。これは、所属するグループ（Role）と属性ベースの条件を組み合わせて権限を決定するというものです。
最後に、これらのQRコードを共有させていただきます。CedarとAmazon Verified Permissionsについてさらに詳しく知りたい方は、Amazon Verified Permissionsに関する多くの動画を公開しているYouTubeチャンネルがあります。特に、Amazon Verified PermissionsとCognitoの使用に関する動画があります。また、Cedar Policyランゲージについて学べるcedarPolicy.comというマイクロサイトもあり、そこではCedarポリシーの作成方法を学び、プレイグラウンドでテストすることができます。お時間をいただき、ありがとうございました。re:Inventの残りの時間をお楽しみください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion