Serverless App Engine (SAE) は、Alibaba Cloud Resource Access Management (RAM) を通じて権限管理を実装します。権限管理機能を使用すると、リソースデータへのアクセスを分離および制御して、データのセキュリティを確保できます。このトピックでは、企業の日常的なビジネス運用を例として、SAE 権限管理のアプリケーションシナリオと機能の実装について説明します。
機能概要
SAE の権限管理を体系的に理解する必要がある場合は、このトピックのアプリケーションシナリオの例を通して、SAE に関連する権限の機能を段階的に学習できます。詳細については、「背景情報」および「ビジネスシナリオ」をご参照ください。
権限管理機能に精通している場合は、必要に応じて次のトピックで関連情報を見つけることができます。
権限ポリシーと例: 権限ポリシーの基本概念、SAE でサポートされている権限ポリシー、および権限ポリシーの例について説明します。
SAE 権限アシスタント: SAE 権限アシスタントツールを使用して権限ステートメントを生成し、カスタムポリシー設定を簡素化する方法について説明します。
RAM ユーザーへの権限付与: RAM ユーザーを作成し、必要に応じて権限を付与する方法について説明します。
RAM ロールへの権限付与: RAM ロールを作成して権限を付与し、ロール ID を持つセキュリティトークンを使用して承認済みリソースへのアクセスを許可する方法について説明します。
連絡先管理: 指定した連絡先の権限ルールを設定したり、通知を送信したりする方法について説明します。
操作の承認: SAE プラットフォームの重要な機能の承認プロセスを設定して、操作権限の詳細な制御を実装する方法について説明します。
サービスリンクロール: SAE がサービスリンクロールを介して他のクラウドリソースへのアクセス権限を取得する方法について説明します。
背景情報
SAE でホストされているアプリケーションには、複数のサービスまたはサブシステムが含まれる場合があり、これらは異なるチームまたはメンバーによって開発および保守される場合があります。SAE は、アカウントシステムと一連の権限管理操作を通じて、エンタープライズレベルの権限管理システムを提供します。これにより、アプリケーション、リソース、およびデータへのアクセスを分離および制御して、セキュリティを確保できます。
企業 A は、Alibaba Cloud アカウント A (プライマリアカウント) を通じて SAE サービスを購入しました。当初、企業内の複数の従業員がこのアカウントを共有していました。ビジネスの成長に伴い、従業員が増え、単一のアカウントを共有すると、責任を明確に分担することが困難になり、セキュリティリスクが生じました。これらの問題を解決するために、企業 A は RAM の機能を使用して、さまざまな従業員にさまざまな権限を付与し、さまざまな部門間で請求を分割しました。

ビジネスシナリオ
シナリオ 1
企業 A は、従業員の責任を明確にし、権限を付与したいと考えています。
従業員の責任を明確にするために、企業 A は Alibaba Cloud アカウント A を使用して複数の RAM ユーザーを作成し、これらのユーザーにさまざまな権限を付与できます。その後、従業員は RAM ユーザーを使用してさまざまなリソースにアクセスできます。企業 A は、SAE 上でアプリケーションをホストするためのリソースを購入しました。したがって、企業 A はまず、RAM における SAE の権限ポリシーと権限付与の構成例を理解する必要があります。RAM は次のポリシーをサポートしています。
システムポリシーは Alibaba Cloud によって作成および更新されます。これらのポリシーは使用できますが、変更はできません。
カスタムポリシー: カスタムポリシーを作成、更新、削除し、その更新を維持できます。
一部のシナリオでは、SAE は特定の機能を完了するために、他のクラウドサービスへのアクセス権限を取得する必要があります。たとえば、アプリケーションの作成時に仮想プライベートクラウド (VPC) などのリソースに関する情報を取得したい場合、サービスにリンクされた AliyunServiceRoleForSAE ロールを使用して、VPC などの関連サービスにアクセスするために必要な権限を取得できます。
詳細については、「権限ポリシーと例」および「サービスリンクロール」をご参照ください。
シナリオ 2
企業 A は、従業員に詳細な権限を付与したいと考えています。
権限ポリシーについて学習した後、企業 A は、まず従業員にシステム権限を設定できると考えています。これは、SAE リソースの読み取り権限など、一般的な共通の権限です。システムポリシーがビジネス要件を満たさない場合、企業 A はカスタムポリシーを作成して、詳細なアクセスの制御を実装できます。
カスタムポリシーを構成する際、SAE 権限アシスタントを使用すると、初期のスクリプト編集作業を簡素化できます。企業 A は、自動生成された完全なスクリプトを RAM コンソールにコピーし、対応するカスタムポリシーを作成して、RAM ユーザーに付与できます。これにより、RAM コンソールで直接操作するときに発生する可能性のあるエラーを効果的に回避できます。
詳細については、「SAE 権限アシスタント」をご参照ください。
シナリオ 3
企業 A は、従業員のために RAM ユーザーを作成し、その RAM ユーザーに権限を付与したいと考えています。
権限ポリシーについて学習した後、企業 A は RAM ユーザーを作成し、さまざまな従業員に対してこれらのユーザーに必要な権限を付与しようとします。
詳細については、「RAM ユーザーへの権限付与」をご参照ください。
シナリオ 4
企業 A は、パートナー企業とワークロードを共有したいと考えています。この場合、企業 A は RAM ユーザーを作成し、アカウントをまたいで RAM ユーザーに権限を付与する必要があります。
企業 A は、ビジネスの成長に伴い企業 B と良好なパートナーシップを築いており、企業 B にビジネスの一部を管理する権限を付与したいと考えています。企業 A の要件:
企業 A は、自社の業務システムに集中し、SAE のリソース所有者としてのみ機能したいと考えています。企業 A は、アプリケーションの公開、アプリケーション管理、自動弾力性、アプリケーションのワンクリックでの起動と停止、アプリケーション監視などの一部のサービスを管理する権限を企業 B に付与したいと考えています。
企業 B の従業員が入社または退社するたびに、企業 A は権限設定を変更する必要はありません。企業 B は、企業 A のリソースアクセス権限を企業 B の RAM ユーザーにさらに割り当てることができ、従業員やアプリケーションのリソースへのアクセス権限や操作権限を細かく制御できます。
企業 A と企業 B の間の契約が終了した場合、企業 A は企業 B から権限を取り消すことができます。
詳細については、「RAM ロールへの権限付与」をご参照ください。
シナリオ 5
企業 A は、各アクセス承認プロセスを管理したいと考えています。
企業 A は、Alibaba Cloud アカウント A 内に、テスト環境、開発環境、ステージング環境、オンライン環境など、複数の名前空間をデプロイしています。企業 A は、オンライン環境のリソースへのアクセスを厳密に制御したいと考えています。権限のない開発者は、オンライン環境のリソースへのアクセスを拒否されます。これにより、環境のクラッシュを防ぎます。企業 A は、アクセス承認プロセスを構成し、承認通知を受信して、操作権限に対する詳細なアクセスの制御を実行できます。