※ 本記事は、Ayman Elmenshawyによる”Behind the Scenes: Modernized IAM architecture with OCI Resource Principals“を翻訳したものです。
2025年6月9日
クラウドは、デジタル環境を再構築しています。Cloud Zeroは、2023年の時点で、グローバル・クラウド・コンピューティング市場が5,000億ドルを超え、2028年までに倍増、と推定しています。この成長は、未開拓のクラウドの巨大な可能性を浮き彫りにしています。クラウド・サービス・プロバイダー(CSP)で働いている私は、クラウドがスケーラビリティを実現し、メンテナンスを簡素化し、組織がコア目標に集中できるようにする方法を直接見てきました。しかし、1つの質問が残ります。すべての組織がクラウドに移行していないのはなぜでしょうか?
今年のCloud WorldでOracle Cloud Infrastructure (OCI)は、クラウド・テクノロジーがどこまで限界を押し広げられるかを示し、最大131,000ノードのゼタスケール・スーパークラスタを提供する計画を発表しました。このオファリングの規模は、クラウド領域に存在する独自の課題と機会を強調しています。つまり、システムをセキュアかつシームレスに連携させることができます。相互運用性は単なる技術的な問題ではなく、真にグローバルでコネクテッドなクラウド・エコシステムの基盤です。相互運用性はクラウド導入の大きな原動力ですが、この移行を検討している企業にとって、セキュリティは依然として重要な考慮事項です。プラットフォームや地域にわたってデータが流れる世界では、機密情報を確実に保護することが重要です。クラウド・コンピューティングは、驚くべき俊敏性とスケーラビリティを提供しますが、これらの利点には、進化し続ける脅威からデータを保護する責任があります。OCIを含む主要なクラウド・プロバイダーは、この動的な状況に対応するために、セキュリティ・プロトコルを継続的に推進し、組織がクラウドで自信を持って運用できるようにします。しかし、課題はバランスを取ることにあります。セキュリティ対策は堅牢で、ビジネスが摩擦を起こすことなく実施できるほどシンプルである必要があります。セキュリティ対策が厳しすぎたり複雑すぎたりすると、複雑なパスワード・ポリシーがユーザーを安全でない慣習に押し付ける場合など、脆弱性自体が発生するリスクがあります。
このブログ投稿の過程で、OCIエンジニアが顧客に適切なサイズのセキュリティ・ソリューションを作成するためにどのように取り組んだかについて説明します。このソリューションにより、お客様はセキュリティ対策をファインチューニングし、誰が何にアクセスできるかを制御できます。このアプローチでは、OCIの特許を取得したResource Principals(RP)を活用します。これは、各クラウド・リソースに独自のアイデンティティを提供することで、アイデンティティの課題に対処するのに役立ちます。これにより、リソースによる認証コールや認可コールなど、リソース相互作用をより適切に追跡および監査できます。最後に、OCIが培ってきた機能のポートフォリオを体験し、RPを実現します。
リソース・プリンシパル(RP)の増加
2018年まで、OCIのお客様は、「サービス・データベースのキーへのアクセスを許可する」などのリソースへのアクセス権限をサービスに付与するポリシーを作成しました。シンプルですが、これは、キーがより広範なサービスではなく、特定のデータベースだけにアクセスできるようにすることに懸念が生じました。バックアップと同じように、データベース・サービス全体ではなく顧客のデータベースのみがストレージ・バケットに書き込む必要があります。これは、セキュリティを損なうことなくセキュアなシステム・インタラクションを実現するという、クラウドの重要な課題を浮き彫りにしています。
アプリケーションがオブジェクト・ストレージにバックアップするデータベースなどの様々なサービスとますます通信するようになるにつれ、課題は「誰が誰と話しているのか」になります。従来、システムが相互に通信する場合、資格証明の共有や、マシン用のユーザー名やパスワードなどの人工資格証明の作成に依存していました。しかし、機械が人物のふりをするこのアプローチは、今日のクラウド・エコシステムにとどまりません。こうした相互作用の確保には、より賢明な解決策が必要でした。
この必要性がリソース・プリンシパルの導入につながりました。RPは、仮想マシン、データベース、関数、OKEコンテナなどの個々のリソースに対して個別のセキュアなアイデンティティを提供します。これにより、顧客は、「コンパートメント内の特定のIDのデータベースが自分のキーにアクセスできるようにする」などの細かいポリシーを定義できます。目標は、セキュリティの境界を改善するだけでなく、管理しやすくすることでした。RPでは、各リソースに必要な権限のみを持ちます。ここで、リソース・プリンシパル・セッション・トークン(RPST)が再生されます。たとえば、「IDがocid1.container.1111111111111111111111のコンテナ・タイプのリソースです。」のように、特定のリソース・タイプのアイデンティティをアサートする短命トークンです。RPSTを使用すると、リソースは独自のアイデンティティでAPIコールを安全に実行でき、最新のクラウド・インタラクションのためのより論理的で安全な認証システムを作成できます。
RPは、ユーザー「クラウド・カスタマ」でも「クラウド・サービス」でもなく、お客様が使用するクラウド・リソースである新しいアイデンティティの導入です。RPでは、クラウド・リソースが独自のアイデンティティを持つことができ、サービス・アカウント・アイデンティティを使用する必要がなくなります。また、リソース資格証明のローテーションもサポートしているため、攻撃者がリソース資格証明を盗む場合、短時間のみ有効です。現在、リソースには独自のアイデンティティがあるため、非常にファインチューニングされた方法で空きリソースを管理できます。これにより、詳細な監査が可能になり、バックグラウンドで実際に何が起こるか、および資格証明を使用してアクションを実行したユーザーが反映されます。何よりも、顧客は資格証明のローテーションについて心配する必要はありません。RPは、当社のサービスにガードレールを直接構築することを可能にしました。ポリシーをファインチューニングし、サービス・レベルではなくリソース・レベルで権限を付与することで、混乱した副問題を回避しました。これにより、サービスが誤って、または悪意を持って、ある顧客の権限を使用して別の顧客の利益を得ることができないようになります。エンジニアとして、ミスは起こります。この保護は、大きな安心です。
図1: リソース・プリンシパルの相互作用フロー
しかし、この概念をすべてのOCIリソースに導入する前に、どこかで開始する必要があり、コンピュート・インスタンスは完璧なテスト環境でした。そこでインスタンス・プリンシパルが登場しました。リソースベースのアイデンティティの最初の実用的な適用と考えてください。
インスタンス・プリンシパル OCIの最初のリソース・プリンシパル
2017年にアイデンティティ・チームに加わったとき、私はインスタンス・プリンシパル・アイデンティティに取り組んで、コンピュート・インスタンスが独自の資格証明を持つようにしました。これは、顧客が特定の権限を持つプロセスを実行できるため、ユーザー資格証明を共有したり、管理しにくいサービス・アカウントを作成する必要がなくなります。また、マシンに関連付けられた資格証明がユーザーを偽装できなくなったため、不正アクセスを防止します。
他のクラウド・プロバイダが通常のオペレータ資格情報ではなくサービス・アカウントを使用した場合でも、他のセキュリティ上の懸念が生じました。これらの資格証明はどのようにローテーションされますか。これらのサービス・アカウントはユーザー・アカウントに関連付けられますか。サービス・アカウントのローテーション中にサービスの継続性をどのように保証しますか。
ですから、OCIの最初の週の後、これまで使用したことのない3つの言語(Java、Python、Go)でコードを記述することを学習し、2つの重要なサービス(公開キー・インフラストラクチャ(PKI)とアイデンティティ)に取り組んでいます。刺激的で挑戦的でした。幸いなことに、このコードは自明であり、OCIはすべての人に、潜在能力を最大限に引き出し、一緒に成功するために必要なツール、プロセス、リソースを提供します。これが私の最初の機能であり、OCIの最初の導入者である米国の大手銀行が、本番の使用を熱心に待っていることを知っていました。この機能を提供することは、私にとって重要なマイルストーンでした。短時間で新しい会社で最初のプロジェクトを成功させただけでなく、初期バージョンのRPに貢献し、今後の長い旅に出ました。銀行の技術チームからは、「私が何もしなくてもうまくいく 」と好意的なフィードバックをもらいました。
当初、OCIのすべてのコンピュート・インスタンスは、署名付き証明書に埋め込まれた秘密キーと公開キーという独自のインスタンス資格証明でブートストラップされました。これらの資格証明は、ホストで実行されているエージェントによって、2時間ごとに自動的にローテーションされました。インスタンス・プリンシパルの導入は、各コンピュート・インスタンスに独自のアイデンティティを提供し、ファインチューニングされた精度で権限を付与する重要なステップを踏み出しました。インスタンス・プリンシパルは成功しましたが、コンピュート・インスタンスのアイデンティティの課題に対処するだけで、他のクラウド・リソースには拡張されませんでした。これは、RPへの移行の始まりでしたが、クラウド・エコシステム全体のアイデンティティ管理を解決するには、さらに多くのことが必要でした。
スタック・リソース・プリンシパルで成功を繰り返す
OCIコンピュート・インスタンスにファイングレイン・アイデンティティを正常に付与した後、OracleがRPをデータベースに拡張するのは自然なステップでした。各Oracleデータベースには独自のアイデンティティが付与されているため、暗号化のために顧客のボールト・キーへの安全なアクセスが可能です。これにより、特定の権限をデータベースに直接付与できるため、セキュアで正確なアクセスが可能になります。
ここでは、少し手間がかかります。データベースはコンピュート・インスタンス(すでに独自のインスタンス・プリンシパルがある)でホストされますが、コンピュート・インスタンスは顧客テナントではなくデータベース・サービスによって所有されます。そのため、インスタンス・プリンシパル・アイデンティティを使用して、顧客テナントでデータベース・シナリオを有効にできませんでした。そこで、この問題を解決するために積層アイデンティティの概念を使用することにしました。
コンピュート・インスタンス・アイデンティティを信頼の初期ソースとして使用し、その上にデータベースのアイデンティティをスタックします。まるでホテルにチェックインしているかのよう。予約を請求するためにIDを表示すると、ホテルでは部屋キー(自分専用の個別の識別子)が提供されます。これで、データベースはスタック・アイデンティティを使用してカスタマ・ボールト・キーにアクセスし、自身を暗号化できるようになりました。最高の部分? お客様は、キーへのアクセスを制御できるため、データベースのみがシンプルで詳細なポリシーを使用してキーを使用できます。この権限は、データベース・サービス自体ではなく、テナンシ内のデータベース・インスタンスに明示的に割り当てられます。こうしてRPが誕生した。その革新性とシンプルさにより、Stacked RPアーキテクチャの特許を取得できました。
もちろん、途中でいくつかの障害に遭遇しました。最初に、データベース・インスタンスに明示的に専用の新しいサービスを構築しようとしました。サービスは常時稼働しており、新しいデータベースが顧客テナンシ内のすべてにアクセスする必要がある場合、サービスがそれを容易にします。ゲストを自分の部屋に護衛するためにホテルのスタッフを雇うように考えてください。機能しましたが、スケーラブルではありませんでした。
スタックRPでは、各データベースは、データベースがホストされているコンピュート・インスタンスに基づいてIDを持ちます。このコンピュート・インスタンス・アイデンティティを使用して、別のアイデンティティをスタックし、必要な顧客リソースにアクセスします。
スタックされたRPには制限があり、専用のコンピュート・インスタンスを持つデータベースなどのリソースに最適です。OCI Functionsなどのサーバーレス・リソースをサポートするために、エフェメラル・リソース・タイプを導入しました。
スタックRPは、データベース・シナリオに最適です。ただし、すべてのクラウド・リソースがデータベースと同様に永続的であるわけではなく、すべて独自の専用コンピュート・インスタンスを持つわけでもありません。そのため、OCI Functionsなどのリソースに一時的なリソース概念を導入する必要があり、開始してタスクを実行し、消滅しました。
当社は、エフェメラルRPの最初の顧客として、OCI Functionsエンジニアと緊密に連携しました。関数リソース情報を使用して、数分から数時間の範囲で時間制限が変動するセッション・トークンが割り当てられます。このセッション・トークンは更新されるとは予想されず、リソースに新しいトークンをリクエストするメカニズムもありません。このセッション・トークンを使用するリソースには、Ephemeral RP Patentで説明されているように、トークンの同じ存続期間と一致する短い存続期間があることが期待されます。
図2: OCI APIを呼び出すために、データベースIDをコンピュートIDの上に積み重ねたデータベース・リソース。
リーダーシップは、同じ顧客に対応し、プロバイダ間の安全な通信をサポートしているマルチクラウド・プロバイダの未来を認識しました。AWSでのSQLデータベース・サポートから、AzureおよびGCPのExadataに拡張されました。課題は、セキュアな資格証明のリフレッシュを確保しながら、OCI外のリソースにアイデンティティを付与することでした。長期にわたるRPは、これらのニーズに対応し、セキュアなインタラクションと資格証明のローテーションを実現しました。
Long-Living RPには、long-livingリソースのセッション・トークンをリフレッシュするための2つのモードがあります。1つはプッシュ・モデルで、現在のセッション・トークンが(理想的にはその存続期間の半分の間)期限切れになる前に、新しいセッション・トークンをリソースに発行するサービスです。もう1つは、リソースに独自の初期資格証明があるプル・モデルです。このプル・モデルでは、リソースは初期資格証明を使用して独自のサービスをコールし、サービスがリソースに対して承認する中間トークンを取得します。この中間トークンには、すべてのリソース情報が含まれます。次に、リソースは、初期資格証明と中間トークンを使用して、有効なトークンがなく、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のブートストラップ中にサブリソース・プリンシパルの作成を開始します。たとえば、顧客は、データベース、バケット、キーRPなどの複数のRPから内部的に構成されるFusion Pod RPを作成できます。様々な機能オファリングを持つ様々なFusion Podは、様々なRPセットで構成されます。
私たちは常にセキュリティとシンプルさを最優先にしています。Fusion Podのような大規模なリソースのサブコンポーネントに対するすべてのポリシーと権限を顧客が管理することは悪夢であり、新しいサブリソースを導入するたびに新しいポリシーを追加する必要があります。ネストされたRPは、親リソースのIDをサブリソースと共有できるようにすることで、これを簡単かつ安全な方法で対処します。
顧客の観点からは、Fusion Podが独自のキーにアクセスし、独自のバケットに書き込むことができます。内部的には、Podリソース内のOracle関数がPodアイデンティティを継承し、それを使用してキーを読み取り、データベースを暗号化できます。また、Pod内のデータベースがPodアイデンティティを継承し、それを使用してデータベース・バックアップをバケットにアップロードすることもできます。すべてをきちんと安全かつ簡単に実行できます。
次のグラフに示すように、メイン・リソースには複数のサブリソースが含まれています。顧客は親リソースとのみやり取りし、親リソースに権限を付与します。親リソースは、サブリソースにこれらの権限を継承することを許可します。
図3: ネストされたRPブートストラップ処理
RPトークンベースのMTLS接続の導入
クラウド・テクノロジーの核となるのは、自律性であり、安全性を確保しながら予測可能なシナリオと予測不可能なシナリオの両方をナビゲートすることです。クラウド内の何千ものサービス間の接続性を高めることの重要性を認識することが重要です。証明書を使用したmTLSは、エンティティが証明書によって認識されるほとんどのシナリオでうまく機能しますが、RPの導入とクラウド・リソースのトークン化により、コミュニケーション・パターンにニーズと機会がもたらされました。オラクルの革新的でシンプルなソリューションRPトークンベースのmTLS接続を導入することで、そのニーズを満たしています。リソースが独自のトークンを使用して、mTls接続の確立に使用できる自己署名証明書を発行する場合。証明書は自己署名されていますが、トークンと信頼できるトークン発行者に連鎖して、必要な信頼を確立できます。
図4: RPトークンベースのMTLS信頼チェーン
まとめ
Oracle Resource Principalsのジャーニーは、インスタンス・アイデンティティをコンピュートするシンプルなソリューションとして始まりました。時間の経過とともに、クラウド全体で多様なリソース・アイデンティティを管理するための堅牢なフレームワークへと進化しました。クラウドとオンプレミスの景観が相互接続される度合いが増す中でも、Oracleはセキュリティと機能をシームレスにバランスさせる方法を開拓しました。
スタックRP、エフェメラル・アイデンティティ、long-livingリソース・モデルなどの機能の導入は、様々なリソース存続期間およびシナリオの固有の要件に対処するためのOracleのコミットメントを反映しています。これらのイノベーションは、複雑なアイデンティティ管理の課題を簡素化すると同時に、顧客がリソースの権限をきめ細かい精度で制御できるようにするというOracleの献身を強調します。RPアーキテクチャのマルチクラウド・シナリオ、オンプレミスの統合、および多様なアイデンティティ・ニーズのサポートは、クラウドのセキュリティと相互運用性に対するOracleの先進的なアプローチの証です。
OracleのRPジャーニーは、ますます相互に接続されるデジタル環境全体でアイデンティティ管理の未来を形作り続けるであろう、継続的な改善とクラウド・セキュリティへのコミットメントというレガシーを反映しています。
リソース・プリンシパルを利用して柔軟でファインチューニングされたセキュリティ・クラウド・エクスペリエンスを実現する方法の詳細は、次のリソースを参照してください: