Resource Access Management:ID と権限のベストプラクティス

ベストプラクティス: Alibaba Cloud アカウントは、Linux のルートユーザーのようなものです。完全な権限を持ち、日常的な使用には適していません。以下のベストプラクティスに従ってください:

1. 日常の管理および技術的な操作のために、管理者権限を持つ RAM ユーザーを特別に作成します。

2. Alibaba Cloud アカウントは、絶対に必要な場合にのみ使用します。パスワードと、多要素認証 (MFA) 認証情報などの関連する認証情報を安全に保管します。

3. すべての日常的な操作は、RAM 管理者ユーザーを使用して実行します。これにより、日常の作業環境で Alibaba Cloud アカウントが公開されるのを防ぎます。

推奨される操作:

• 個別の RAM ユーザーの作成: まず、管理者権限を持つ RAM ユーザーを作成します。詳細については、「管理者として RAM ユーザーを作成する」をご参照ください。次に、組織の各メンバーに対して個別の RAM ユーザーを作成します。詳細については、「RAM ユーザーの作成と権限付与」をご参照ください。

• Alibaba Cloud アカウントの MFA を有効にする: 「アカウントの MFA を設定する」の手順に従って、Alibaba Cloud アカウントのセキュリティ強化を完了します。アカウントは必要な場合にのみ使用し、パスワードと MFA 認証情報を安全に保管します。

ベストプラクティス: 人間の ID では、ユーザー名とパスワードを保護することが重要です。いくつかの方法でログインセキュリティを向上させることができます。複雑なパスワード、定期的なローテーション、および MFA は、パスワード認証情報を解読する難易度を大幅に高めます。

RAM 機能の操作ガイド:

• パスワードの複雑さを増す: RAM ユーザーのパスワードポリシー を設定して、パスワードのセキュリティを強化します。最小長、複雑さの要件、有効期間 (最大 90 日など)、およびログイン試行回数を設定できます。

• RAM ユーザーに MFA を強制する: MFA は、パスワードに加えて強力な第 2 の防御層を提供します。パスワードが漏洩した場合でも、不正なログインを効果的にブロックできます。アカウント配下のすべての RAM ユーザーに [ログインに MFA を使用] するよう要求できます。詳細については、「RAM ユーザーのセキュリティ設定を管理する」をご参照ください。

ベストプラクティス: シングルサインオン (SSO) を使用して、ID 認証を統合された企業の ID プロバイダー (IdP) に委任します。これにより、クラウドで個別のパスワードシステムを維持する必要がなくなります。さらに、従業員のオンボーディング、オフボーディング、権限の変更はすべて IdP で管理できます。これにより、ID のライフサイクル管理が一元化されます。

推奨される操作: RAM の SSO 管理機能を使用して、Active Directory や Okta などの企業の IdP を、Security Assertion Markup Language (SAML) 2.0 または OpenID Connect (OIDC) プロトコルに基づいて Alibaba Cloud の ID システムと連携させます。環境とログインのニーズに基づいて、ユーザーベース SSO または ロールベース SSO を設定します。

ベストプラクティス: 永続的な AccessKey は、手動で削除されるまで永続的に有効です。AccessKey が漏洩した場合、脅威は持続します。対照的に、[RAM ロール] を引き受けることによって取得された一時的な セキュリティトークンサービス (STS) トークン は、ロールの最大セッション期間 (時間単位で測定) が経過すると自動的に期限切れになります。STS トークンが誤って漏洩した場合でも、悪用されるタイムウィンドウは非常に小さいです。

推奨される操作: ECS インスタンスロールの引き受け、コンテナーインスタンスロールの引き受け、または Function Compute ロールの引き受けなどの AccessKey フリーのソリューションを使用して、STS トークンを取得します。このアプローチにより、AccessKey の公開を完全に回避できます。詳細については、「アクセス認証情報を使用して Alibaba Cloud OpenAPI にアクセスするためのベストプラクティス」をご参照ください。

ベストプラクティス: ローカルでの開発やデバッグなど、[STS トークン] を使用できないシナリオでは、永続的な [AccessKey] を使用する必要がある場合があります。この場合、Alibaba Cloud アカウントの [AccessKey] の使用は避けてください。各 [AccessKey] が 1 つの環境で 1 つのアプリケーションにのみ使用されるようにし、定期的にローテーションしてください。

推奨される操作:

• Alibaba Cloud アカウントの AccessKey を使用しない: [AccessKey] を使用する必要があるシナリオでは、代わりに適切な権限を持つ RAM ユーザーの [AccessKey] を使用することをお勧めします。

• AccessKey を共有しない: 各アプリケーションと環境 (開発、テスト、本番) ごとに、個別の [RAM ユーザー] と専用の [AccessKey] を作成します。詳細については、「AccessKey の作成」をご参照ください。

• 最小権限の付与: 特定のシナリオに合わせて、[RAM ユーザー] に関連付けられた [AccessKey] に最小権限ポリシーを付与します。定期的に 過剰な権限を検出 し、必要に応じて ポリシーの付与を管理 します。

• 認証情報をハードコーディングしない: コードリポジトリに [AccessKey] をプレーンテキストで書き込まないでください。代わりに、システム環境変数を設定する か、KMS 認証情報管理 を使用して [AccessKey] を管理します。

• アクセス制限: ネットワークアクセスポリシーを設定して、AccessKey のアクセスを特定の IP アドレスに制限します。詳細については、「AccessKey ネットワークアクセス制限ポリシー」をご参照ください。

• アイドル状態の AccessKey を速やかに無効化および失効させる: AccessKey の最大アイドル期間を 365 日未満の値に設定します。90 日の期間が推奨されます。詳細については、「RAM ユーザーのセキュリティ設定を管理する」をご参照ください。

• 監視と監査: ActionTrail を使用して AccessKey の使用状況を監視 し、異常な動作を速やかに検出します。

ベストプラクティス: ID には、意図したタスクを完了するために必要な最小限の権限のみを付与します。これにより、認証情報が盗まれた場合の潜在的な影響を最小限に抑えることができます。

推奨される操作:

• カスタムポリシーの使用: 管理者以外のシナリオでは、Administrator などの広範なシステムポリシーの使用を避けてください。代わりに、詳細な権限付与のために カスタム権限ポリシー を作成します。ポリシーでは、リソース (Resource)、操作 (Action/NotAction)、および条件 (Condition) を明確に指定します。

• 権限を定期的にレビューする: 定期的に 過剰な権限を検出 し、必要に応じて ポリシーの付与を管理 します。

ベストプラクティス: 職務責任に基づいて権限をアタッチします。単一の [RAM ユーザー] の権限変更は、ユーザーが所属する [RAM ユーザーグループ] を調整することで簡素化できます。このアプローチにより、管理効率が向上し、ロール間の一貫性が確保されます。

推奨される操作:

1. RAM ユーザーグループの作成: ネットワーク管理者やアプリケーション開発者向けのグループなど、組織内の職務ロールに基づいて RAM ユーザーグループを作成 します。

2. 権限ポリシーの設定: ポリシーを [RAM ユーザー] に直接アタッチするのではなく、職務責任に基づいて RAM ユーザーグループに権限を付与 します。

ベストプラクティス: 複数の Alibaba Cloud アカウントを持つ組織では、[リソースディレクトリ] のコントロールポリシーを使用して、メンバーアカウント内の RAM ID の権限範囲を制限します。

推奨される操作: リソースディレクトリが有効になっているマルチアカウント環境で、メンバーアカウントの [RAM ユーザー] または [RAM ロール] が Alibaba Cloud サービスにアクセスすると、Alibaba Cloud はまずコントロールポリシーをチェックし、次にアカウント内の RAM 権限をチェックします。詳細については、「コントロールポリシー」をご参照ください。コントロールポリシーをアタッチする前に、まず小規模なテストを実行して、ポリシーが有効であり、期待どおりに機能することを確認することをお勧めします。その後、ポリシーをフォルダやメンバーなどのすべてのターゲットノードにアタッチできます。