舞台裏: : OCIリソース・プリンシパルを使用したIAMアーキテクチャの最新化 (2025/04/22)

https://blogs.oracle.com/cloud-infrastructure/post/behind-the-scenes-iam-oci-resource-principals

投稿者：Ayman Elmenshawy | Consulting Member of Technical Staff

クラウドはデジタル環境を再構築しています。Cloud Zeroは、2023年現在、グローバル・クラウド・コンピューティング市場は5,000億ドルを超え、2028年までに倍増したと推定しています。この成長は、未開拓のクラウドの巨大な可能性を浮き彫りにしています。クラウド・サービス・プロバイダ(CSP)で働くと、クラウドがスケーラビリティを可能にし、メンテナンスを簡素化し、組織がコア目標に集中できるようになることが初めてわかりました。しかし、1つの疑問が残ります。なぜすべての組織がクラウドに移行しないのでしょうか。

今年のCloud Worldでは、Oracle Cloud Infrastructure(OCI)が、クラウド・テクノロジがどれだけ限界を押し広げることができるかを発表し、最大131,000のノードを備えたゼッタスケールのスーパークラスタを提供する計画を発表しました。この製品の規模を問わず、クラウド空間に存在する固有の課題や機会が浮かび上がります。システムは安全かつシームレスに連携できます。相互運用性は単なる技術的な懸念ではなく、真にグローバルでコネクテッドなクラウド・エコシステムの基盤です。相互運用性はクラウドの採用を後押しする主要な原動力ですが、セキュリティは依然としてこの動きを検討している企業にとって極めて重要な考慮事項です。データがプラットフォームや地域をまたがって流れる世界では、機密情報を保護することが重要です。クラウド・コンピューティングは、驚異的なアジリティとスケーラビリティを提供しますが、これらの利点には、進化し続ける脅威からデータを保護する責任があります。OCIを含む大手クラウド・プロバイダーは、このダイナミックな環境に対応するために、セキュリティ・プロトコルを継続的に推進し、組織がクラウドで自信を持って運用できるようにします。しかし、課題はバランスを取ることにある: セキュリティ対策は、企業が摩擦を起こさずに実装するのに十分な堅牢でシンプルでなければなりません。セキュリティ対策が厳格すぎたり複雑すぎたりすると、複雑なパスワード・ポリシーによってユーザーが安全でない慣行に追い込まれる場合など、脆弱性自体になるリスクがあります。

このブログ記事では、OCIエンジニアがお客様に適したサイズのセキュリティ・ソリューションを作成するためにどのように取り組んできたかを紹介します。このソリューションにより、お客様はセキュリティ対策を微調整し、誰が何にアクセスできるかを制御できます。このアプローチでは、OCIの特許を取得したリソース・プリンシパル(RP)を活用し、各クラウド・リソースに独自のアイデンティティを提供することで、アイデンティティの課題に対処できます。これにより、リソースによる認証および認可コールなど、リソース相互作用の追跡および監査が向上します。最後に、OCIが開発した機能のポートフォリオを通じて、RPの実現を図ります。

リソース・プリンシパル(RP)の増加

OCIのお客様は、2018年まで、「サービス・データベースが自分のキーにアクセスできるようにする」などのリソースにアクセスする権限をサービスに付与するポリシーを作成しました。単純なことですが、キーが特定のデータベースにのみアクセス可能であり、より広範なサービスにはアクセスできないという懸念がありました。バックアップの場合も同様で、データベース・サービス全体ではなく、お客様のデータベースのみがストレージ・バケットに書き込む必要があります。これは、セキュリティを損なうことなく安全なシステム・インタラクションを実現するという、クラウドの主要な課題を浮き彫りにしています。

アプリケーションがオブジェクト・ストレージにバックアップするデータベースなどの様々なサービスと通信するようになるにつれて、課題は「誰と話しているのか」になります。従来、システムが相互に通信する場合、資格証明の共有や、マシンのユーザー名やパスワードなどの人工的な資格証明の作成に依存していました。しかし、このアプローチは、機械が人のように見せかけるもので、今日のクラウド・エコシステムには当てはまりません。こうしたインタラクションを確保するためには、より賢明なソリューションが必要でした。

この必要性が、リソース・プリンシパルの導入につながりました。RPは、仮想マシン、データベース、関数、OKEコンテナなどの個々のリソースに対して異なるセキュアなアイデンティティを提供します。これにより、顧客は「自分のコンパートメント内の特定のIDを持つデータベースに自分のキーへのアクセスを許可する」などのきめ細かいポリシーを定義できます。目標は、セキュリティの境界を改善することだけでなく、管理しやすくすることでした。RPでは、各リソースに必要な権限のみを持ちます。ここで、リソース・プリンシパル・セッション・トークン(RPST)が再生されます。たとえば、「I am a resource of type container with ID ocid1.container.111111111111111111111」など、特定のリソース・タイプのアイデンティティをアサートする短期間のトークンです。RPSTを使用すると、リソースは独自のアイデンティティでAPIコールを安全に実行でき、最新のクラウド・インタラクションのためのより論理的で安全な認証システムを作成できます。

RPは、ユーザー「クラウド・カスタマー」でも「クラウド・サービス」でもなく、お客様が使用するクラウド・リソースでもない新しいアイデンティティの導入です。RPを使用すると、クラウド・リソースが独自のアイデンティティを持つことができ、サービス・アカウント・アイデンティティを使用する必要がなくなります。また、リソース資格証明のローテーションもサポートしているため、攻撃者がリソース資格証明を盗んだ場合、短時間のみ有効です。これで、リソースは独自のアイデンティティを持つようになり、フリート・リソースは非常に微調整された方法で管理できるようになります。これにより、バックグラウンドで実際に何が起こるか、および資格証明を使用してアクションを実行した人が反映された詳細な監査が可能になります。何よりも、お客様は資格証明のローテーションについて心配する必要がなくなります。RPは、当社のサービスにガードレールを直接構築することを可能にしました。ポリシーを微調整し、サービス・レベルではなくリソース・レベルで権限を付与することで、混乱する副次的な問題を回避できました。これにより、サービスが、ある顧客の権限を誤ってまたは悪意を持って使用して別の顧客の利益を得ることができないようになります。エンジニアとして、間違いが起こる。この保護機能が組み込まれていることは大きな安心感です。

図1: リソース・プリンシパルの相互作用フロー

しかし、この概念をすべてのOCIリソースに展開する前に、どこかで始める必要があり、コンピュート・インスタンスは完璧なテスト・アースでした。そこで、インスタンス・プリンシパルが登場しました。これは、リソースベースのアイデンティティの最初の実用的な適用と考えてください。

Instance Principals OCIの最初のリソース・プリンシパル

2017年にアイデンティティ・チームに加わったとき、インスタンス・プリンシパル・アイデンティティで作業し、コンピュート・インスタンスに独自の資格証明を持たせることができました。これは、顧客が特定の権限を持つプロセスを実行できるようにするため、ユーザー資格証明を共有したり、管理しにくいサービス・アカウントを作成する必要がなくなります。また、マシンに関連付けられた資格証明はユーザーを偽装できなくなるため、不正アクセスを防止します。

他のクラウド・プロバイダが通常のオペレータ資格証明ではなくサービス・アカウントを使用した場合でも、他のセキュリティ上の懸念が生じました。これらの資格証明はどのようにローテーションされますか。これらのサービス・アカウントはユーザー・アカウントに関連付けられますか。サービス・アカウントのローテーション中にサービスの継続性をどのように保証しますか。

OCIでの最初の1週間後、これまで使用したことのない3つの言語(Java、Python、Go)でコードを書くことを学びながら、公開キー・インフラストラクチャ(PKI)とアイデンティティの2つの重要なサービスに取り組んでいます。刺激的で挑戦的でした。幸いなことに、コードはわかりやすく、OCIは、能力を最大限に発揮し、一緒に成功するために必要なツール、プロセス、リソースで、すべての人を支援します。これが私の最初の機能であり、OCIの最初の導入者の1人である米国の大手銀行が、本番環境の使用を熱心に待っていることを知っていました。この機能の提供は、私にとって重要なマイルストーンでした。短期間で新しい会社で最初のプロジェクトを正常に完了しただけでなく、RPの初期バージョンにも貢献し、今後の長い旅に出ました。銀行のテクノロジー・チームから、「何もせずに機能する」という肯定的なフィードバックを受けました。

最初は、OCIのすべてのコンピュート・インスタンスが、独自のインスタンス資格証明(秘密キーと署名付き証明書に組み込まれた公開キー)でブートストラップされていました。これらの資格証明は、ホストで実行されているエージェントによって2時間ごとに自動的にローテーションされました。インスタンス・プリンシパルの導入は、各コンピュート・インスタンスに独自のアイデンティティを付与し、権限を微調整された精度で付与することで、大きな前進をもたらしました。インスタンス・プリンシパルは成功しましたが、コンピュート・インスタンスのアイデンティティの課題にのみ対処し、他のクラウド・リソースには拡張しませんでした。これにより、RPジャーニーの始まりとなりましたが、クラウド・エコシステム全体でアイデンティティ管理を解決するには、さらに多くのことが必要でした。

スタック・リソース・プリンシパルで成功を繰り返す

OCIコンピュート・インスタンスにファイングレイン・アイデンティティを正常に付与した後は、OracleがRPをデータベースに拡張する自然なステップでした。各Oracleデータベースには独自のアイデンティティが与えられ、暗号化のために顧客のボールト・キーに安全にアクセスできます。これにより、特定の権限をデータベースに直接付与できるため、セキュアで正確なアクセスが保証されます。

ここでは、データベースがコンピュート・インスタンス(すでに独自のインスタンス・プリンシパルを持つ)でホストされますが、コンピュート・インスタンスは顧客テナントではなくデータベース・サービスによって所有されます。そのため、インスタンス・プリンシパル・アイデンティティを使用して、顧客テナントでデータベース・シナリオを有効にできませんでした。そこで、この問題を解決するために、スタック・アイデンティティの概念を使用することにしました。

コンピュート・インスタンス・アイデンティティを信頼の初期ソースとして使用し、データベースのアイデンティティをその上に「スタック」します。まるでホテルにチェックインするかのように。予約を要求するためにIDが表示され、ホテルでは部屋キー(あなただけの個別の識別子)が提供されます。現在、データベースはスタック・アイデンティティを使用して、顧客のボールト・キーにアクセスし、自身を暗号化できます。最良の部分? お客様はキーへのアクセスを制御できるため、シンプルできめ細かいポリシーでキーを使用できるのはデータベースのみです。この権限は、特にデータベース・サービス自体ではなく、テナンシ内のデータベース・インスタンスに割り当てられます。こうして積層RPが誕生した。そのイノベーションとシンプルさにより、Stacked RPアーキテクチャに特許を取得できました。

もちろん、途中でいくつかの障害を乗り越えました。最初に、データベース・インスタンスに明示的に専用の新しいサービスを構築しようとしました。サービスは常に稼働しており、新しいデータベースが顧客テナンシ内の何かにアクセスする必要がある場合、サービスはそれを容易にします。ゲストを部屋に護衛するためにホテルのスタッフを雇うようなものと考えてください。うまくいきましたが、スケーラブルではありませんでした。

スタックRPでは、各データベースは、データベースがホストされているコンピュート・インスタンスに基づいてIDを持ちます。このコンピュート・インスタンス・アイデンティティを使用して別のアイデンティティをスタックし、必要なカスタマ・リソースにアクセスします。

スタックRPにはその制限がありました。専用コンピュート・インスタンスを持つデータベースなどのリソースに最適です。OCI Functionsなどのサーバーレス・リソースをサポートするために、エフェメラル・リソース・タイプを導入しました。

スタックRPは、データベース・シナリオに最適です。ただし、すべてのクラウド・リソースがデータベースと同じように永続的であるわけではなく、すべてに独自の専用コンピュート・インスタンスがあるわけでもありません。そのため、OCI Functionsなどのリソースに一時的なリソース概念を導入し、開始してタスクを実行してから消滅する必要がありました。

当社は、一時的RPの最初の顧客としてOCI Functionsエンジニアと緊密に連携しました。ファンクション・リソース情報を使用して、数分から数時間までの可変時間制限を持つセッション・トークンが割り当てられます。このセッション・トークンは更新されることは予想されず、リソースに新しいトークンをリクエストするメカニズムもありません。このセッション・トークンを使用するリソースは、エフェメラルRP特許で説明されているように、トークンの同じ存続期間と一致する短い存続期間を持つことが期待されます。

図2: OCI APIを呼び出すために、データベース・アイデンティティをコンピュート・アイデンティティの上に積み重ねたスタック・データベース・リソース

リーダーシップは、同じ顧客に対応するマルチクラウド・プロバイダーの将来を認識し、プロバイダー間の安全なコミュニケーションをサポートします。AWSでのSQLデータベースのサポートから、AzureおよびGCPでExadataに拡張されました。課題は、セキュアな資格証明のリフレッシュを確保しながら、OCI以外のリソースにアイデンティティを付与することでした。長生きするRPはこれらのニーズに対応し、セキュアな対話と資格のローテーションを実現します。

長生きするRPには、長生きするリソースのセッション・トークンをリフレッシュするための2つのモードがあります。プッシュ・モデルでは、現在のセッション・トークンが期限切れになる前にサービスによってリソースに新しいセッション・トークンが発行されます(通常は存続期間の半分)。プル・モデルでは、リソースに独自の初期資格証明があります。このプル・モデルでは、リソースは初期資格証明を使用して独自のサービスをコールし、サービスがリソースに対して保証する中間トークンを取得します。この中間トークンには、すべてのリソース情報が含まれます。次に、リソースは、初期資格証明および中間トークンを使用して、有効なトークンがなく、OCI APIをコールする必要がある場合に、アイデンティティからセッション・トークンをリクエストします。プッシュ・モデルとプル・モデルの選択はサービスに任され、リソース自体の接続性に基づきます。Oracleエージェントは、この長生きするRPモデルを採用した最初のサービスの1つです。また、Long-Living RP Patentで説明されているように、公開されたリソース資格証明が最終的に無効になるように、初期資格証明をローテーションする必要があります。

OCIにより、証明書ベースのリソース・プリンシパルによるオンプレミス・サポートが可能

潜在的なクラウドの顧客の多くは、まだ完全にはクラウド上にありません。クラウドに完全にオンボーディングできない場合は、クラウド・リソースをサポートして、オンプレミスのリソースとやり取りしましょう。証明書ベースのRPは、これらのシナリオのソリューションです。クラウドのお客様は、独自のアイデンティティを使用して、新しいクラウド・リソースをOCIに登録します。この登録プロセス中、オンプレミス・リソースはオンボーディング・プロセスを受け、OCI証明書が割り当てられます。これらの証明書は、リソースがRPセッション・トークンをリクエストして他のOCI APIを呼び出すために使用する資格証明として機能します。証明書ベースのRPでは、構築済のセキュリティ・レイヤーがリソース・プリンシパルに導入されました。証明書の有効期限を使用してリソースの存続期間を追跡し、証明書データを使用してリソース・メタデータを格納します。このフローを最初に利用するのは、oracle管理エージェントとWLPエージェントです。弊社のリソースを保護するためにWLPエージェントが導入されましたが、一部のお客様はオンプレミスのハードウェアに対して同じレベルの保護を要求していました。RPは、管理が簡単で安全な方法で私たちのニーズを満たすために再び進化しました。

Fusion AppsおよびMachine Learning Pipelinesでネストされたリソース・プリンシパルの新しい機会

OCIにRPが導入されて以来、より多くのサービスがオンボーディングされています。RPは、サービス・データ・プレーン・オブジェクト/リソースにアイデンティティを与えるために使用されています。従来、リソースは最小のアイデンティティ単位であり、独自のRPSTトークンを取得し、それを使用して他のOCI APIをコールしていました。現在、新しいタイプのリソースが導入され、リソースは複数のリソース(サブリソースで構成される親リソース)で構成されています。顧客は親RPの作成のみを開始します。親リソースは、親RPのブートストラップ中にサブリソース・プリンシパルの作成を開始します。たとえば、顧客はFusion Pod RPを作成できます。このRPは、データベース、バケット、キーRPなどの複数のRPから内部的に構成されます。様々な機能オファリングを持つ様々なFusion Podは、様々なRPセットで構成されます。

常にセキュリティとシンプルさを最優先にしています。お客様が、Fusionポッドなどの大規模なリソースのサブコンポーネントに対するすべてのポリシーおよび権限を管理することは悪夢であり、新しいサブリソースを導入するたびに新しいポリシーを追加する必要があります。ネストされたRPは、親リソースのIDをサブリソースと共有できるようにすることで、これを簡単かつ安全な方法で対処します。

顧客の観点からは、Fusionポッドが独自のキーにアクセスし、独自のバケットに書き込むことが可能になります。内部的には、ポッド・リソース内のOracle関数がポッド・アイデンティティを継承し、それを使用してキーを読み取り、データベースを暗号化できるようにします。また、ポッド内のデータベースはポッド・アイデンティティを継承し、それを使用してデータベース・バックアップをバケットにアップロードすることもできます。これらはすべて、きちんと安全かつ簡単に実行できます。

次のグラフに示すように、メイン・リソースには複数のサブリソースが含まれているため、顧客は親リソースと対話するだけで、親リソースに対する権限を付与します。親リソースは、サブリソースがこれらの権限を継承できるようにすることを決定します。

図3: ネストされたRPブートストラップ・プロセス。

RPトークンベースのMTLS接続の導入

クラウド・テクノロジーの中核は自律性であり、安全性を確保しながら、予測可能なシナリオと予測不可能なシナリオの両方をナビゲートすることです。クラウド内の何千ものサービス間の接続性を高めることの重要性を認識することが重要です。証明書を持つmTLSは、エンティティが証明書によって認識されるシナリオのほとんどで適切に機能しますが、RPの導入とクラウド・リソースのトークン化により、通信パターンでニーズと機会が生まれました。革新的でシンプルなソリューションRPトークンベースのmTLS接続の導入により、ニーズが満たされました。リソースが独自のトークンを使用して、mTls接続の確立に使用できる自己署名証明書を発行する場合。証明書は自己署名されていますが、トークンと信頼できるトークン発行者に連鎖して、必要な信頼を確立できます。

図4:RPトークンベースのMTLS信頼チェーン

まとめ

Oracleのリソース・プリンシパル・ジャーニーは、インスタンス・アイデンティティを計算するためのシンプルなソリューションとして始まりました。時間の経過とともに、クラウド全体で多様なリソース・アイデンティティを管理するための堅牢なフレームワークへと進化しました。クラウドとオンプレミスの環境がますます相互に接続されるようになっても、Oracleはセキュリティと機能とのバランスをシームレスにとる方法を先駆けてきました。

積層RP、一時的アイデンティティ、長期にわたるリソース・モデルなどの機能の導入は、様々なリソース・ライフタイムおよびシナリオの固有の要件に対処するためのOracleのコミットメントを反映しています。これらのイノベーションは、複雑なアイデンティティ管理の課題を簡素化しつつ、顧客がきめ細かい精度でリソースの権限を制御できるようにするOracleの献身を強調しています。マルチクラウド・シナリオ、オンプレミス統合、多様なアイデンティティ・ニーズに対するRPアーキテクチャのサポートは、Oracleのクラウド・セキュリティと相互運用性に対する先見的なアプローチの証です。

OracleのRPジャーニーは、クラウド・セキュリティに対する継続的な改善とコミットメントのレガシーを反映しています。このレガシーは、ますます相互に接続されるデジタル環境で、アイデンティティ管理の未来を形作り続けます。

柔軟で微調整されたセキュリティ・クラウド・エクスペリエンスのためのリソース・プリンシパルの利用の詳細は、次のリソースを参照してください:

• Use Resource Principal to Access Oracle Cloud Infrastructure Resource