ID とは、クラウド環境で操作を実行するエンティティです。クラウドには、主にヒューマン ID とプログラムによる ID の 2 種類の ID があります。
ヒューマン ID は通常、セキュリティ管理者、運用管理管理者、アプリケーション開発者など、組織内の個人を表します。ヒューマン ID は通常、Alibaba Cloud 管理コンソール、コマンドラインインターフェイス (CLI)、または特定のシナリオのクライアントを介してクラウドリソースと対話します。
プログラムによる ID は、アプリケーションまたはサービスを表します。多くの場合、Alibaba Cloud OpenAPI を介してクラウドリソースとデータにアクセスします。
Alibaba Cloud で両方のタイプの ID を管理するには、最小権限のセキュリティ原則に基づいた 2 つのコア原則 (露出期間の短縮と露出面の削減) に従います。
露出期間の短縮とは、可能な限り静的な ID や認証情報の代わりに一時的な ID や認証情報を使用することを意味します。静的な ID や認証情報を使用する場合でも、定期的にローテーションする必要があります。
露出面の削減とは、キーや認証情報を安全に保管することを意味します。異なる ID タイプ間で認証情報や ID を混在させないでください。
Alibaba Cloud でさまざまな種類の ID を管理するための以下のベストプラクティスは、これら 2 つのコア原則に基づいています。
ヒューマン ID
ルート ID の使用を避ける
Alibaba Cloud アカウントを登録すると、ユーザー名とパスワードを使用して Alibaba Cloud 管理コンソールにログインできます。これにより、アカウントの完全な権限を持つルート ID が提供されます。アカウントのパスワードが漏洩した場合、セキュリティリスクは非常に高くなります。複数の人がこの ID を共有すると、各人がアカウントのユーザー名とパスワードを持つことになり、漏洩の可能性が高まります。さらに、複数の人が ID を共有する場合、操作ログにはどの個人が操作を実行したかが表示されないため、ソースを追跡することができません。したがって、ほとんどすべてのシナリオで、Alibaba Cloud Resource Access Management (RAM) ID を使用してクラウドリソースにアクセスする必要があります。Alibaba Cloud アカウントのルート ID の使用は避けてください。ルート ID を使用する必要がある場合は、「より安全なログインメカニズムの確立」セクションのベストプラクティスに従って、セキュリティを向上させてください。
ヒューマン ID のための統合認証の実装
ヒューマン ID の統合認証には、一元化された ID プロバイダー (IdP) を使用します。これにより、ID 管理が簡素化され、組織内のオンプレミス ID とクラウド ID の一貫性が確保されます。従業員の入社や退社など、人事構造が変更された場合、ID を 1 か所で管理できます。クラウド環境のユーザーは、RAM ユーザー名とパスワードなどの別のユーザー名とパスワードを必要としません。組織の IdP 内で ID と認証情報を保護するだけで済みます。一部の組織では、ネットワークアクセス制御メジャーを使用して、IdP をイントラネットからのみアクセスできるようにしています。これにより、ID 認証プロセスに別のセキュリティレイヤーが追加され、社内担当者の ID がさらに保護されます。
Alibaba Cloud は、SAML 2.0 プロトコルに基づくシングルサインオン (SSO) をサポートしています。Alibaba Cloud では、RAM SSO を介して組織の IdP を統合し、ヒューマン ID の統合認証を実装できます。複数の Alibaba Cloud アカウントを持つ複雑な組織の場合は、CloudSSO を使用して、複数のアカウント間で SSO 構成を一元化することもできます。これにより、ID 管理がさらに統合され、効率が向上します。
より安全なログインメカニズムの確立
ヒューマン ID は通常、ユーザー名とパスワードでログインします。ユーザー名とパスワードが漏洩すると、攻撃者はそれらを使用して Alibaba Cloud にログインし、回復不能な損失を引き起こす可能性があります。したがって、これらの認証情報を保護することは、重大なセキュリティメジャーです。次の方法でログインセキュリティを向上させることができます。
パスワード強度を高めます。たとえば、文字数を増やし、数字、大文字と小文字、特殊文字を混在させます。Alibaba Cloud RAM ユーザーの場合、管理者は パスワード強度ルールを設定 して、RAM ユーザーにより複雑なパスワードの使用を強制できます。これにより、パスワードの漏洩やクラッキングのリスクが軽減されます。
パスワードの再利用を避けます。異なるサービス、サイト、またはユーザーに同じパスワードを使用すると、露出面が広がり、漏洩の可能性が高まります。あるサービスまたはユーザーのパスワードが漏洩した場合、攻撃者はそのパスワードを共有する他のサービスにログインしようとする可能性があります。したがって、異なるサービスとユーザーが異なるパスワードを持つようにして、パスワード漏洩のリスクを軽減してください。
パスワードを定期的にローテーションします。パスワードの使用期間が長くなるほど、漏洩のリスクが高まります。パスワードを定期的にリセットすると、単一のパスワードの寿命が短縮され、漏洩のリスクが軽減されます。Alibaba Cloud RAM ユーザーの場合、管理者は パスワード強度ルール でパスワードの有効期限を設定して、定期的なパスワードのローテーションを実装できます。
多要素認証を使用します。多要素認証 (MFA) は、シンプルで効果的なセキュリティプラクティスです。ユーザー名とパスワードに加えて、保護レイヤーを追加します。Alibaba Cloud にログインしたり、機密性の高い操作を実行したりするときは、MFA を使用して 2 次 ID 検証を行い、アカウントをより適切に保護します。Alibaba Cloud は、仮想 MFA や Universal 2nd Factor (U2F) セキュリティキーなど、複数の 2 次認証方式をサポートしています。クラウド内のすべてのヒューマン ID に対して 2 次認証を有効にします。オンプレミスの IdP を使用して統合認証を行う組織の場合は、IdP 側でも 2 次認証オプションを提供する必要があります。
静的 ID の代わりにロールの偽装を使用する
露出面を減らすという原則に基づき、静的な ID の代わりに一時的な ID を使用することで、ID 漏洩のリスクを大幅に減らすことができます。ヒューマン ID の場合、これにより権限モデルを抽象化することもできます。たとえば、職務別にロールを定義でき、これにより権限設定の標準化と管理効率の向上が図れます。
ロールの偽装に基づく SSO を介して、クラウド内のヒューマン ID を管理します。
プログラムによる ID
Alibaba Cloud アカウントの AccessKey を使用しない
Alibaba Cloud アカウントの AccessKey はルート権限を提供し、アカウントの完全な管理権限を付与します。ソース IP アドレスやアクセス時間などの条件を追加して権限を制限することはできません。漏洩した場合、リスクは非常に高くなります。プログラムによるアクセスには、代わりに RAM ユーザーの AccessKey を使用して Alibaba Cloud API を呼び出します。
AccessKey の共有を避ける
複数のプログラムによる ID が AccessKey を共有する場合、またはプログラムによる ID とヒューマン ID が AccessKey を共有する場合、AccessKey に関連付けられた権限はすべてのユースケースをカバーする必要があります。これにより、権限が過度に広範になります。共有シナリオでは、1 か所での漏洩がすべてのアプリケーションに影響します。これにより、漏洩の影響範囲が拡大し、即時修正がより困難になります。本番環境やテスト環境など、同じアプリケーションの異なる環境では、多くの場合、異なるリソースにアクセスする必要があります。同時に、テスト環境のコードは安定性や堅牢性に欠けることが多く、漏洩しやすくなります。同じ AccessKey を共有している場合、テスト環境での漏洩は本番環境に容易に影響を与え、ビジネスセキュリティのリスクを生み出す可能性があります。
したがって、異なるアプリケーション、大規模アプリケーションの異なるモジュール、および同じアプリケーションまたはモジュールの異なる環境 (本番環境やテスト環境など) については、プログラムによる ID 用に個別の AccessKey を作成する必要があります。各 AccessKey には、特定のシナリオで必要な権限のみを付与する必要があります。AccessKey の共有は避けてください。
AccessKey を定期的にローテーションする
ヒューマン ID のユーザー名とパスワードと同様に、AccessKey の使用期間が長くなるほど、漏洩のリスクが高まります。定期的に新しい AccessKey を作成して、アプリケーションが使用している AccessKey を置き換えます。次に、古い AccessKey を無効にして削除し、定期的なローテーションを実現します。または、Alibaba Cloud Key Management Service (KMS) の Secrets Manager 機能を使用して、AccessKey の自動化された定期的なローテーションを実装することもできます。
AccessKey に加えて、他のすべての種類のプログラムによるアクセス認証情報も定期的にローテーションして、認証情報漏洩のリスクを軽減する必要があります。
静的認証情報の代わりに一時的な認証情報を使用する
RAM ユーザーまたは Alibaba Cloud アカウントのルート ID 用に作成された AccessKey は、プログラムによる呼び出しのための静的認証情報です。一度作成されると、認証情報は削除されるまで固定の AccessKey ID と AccessKey Secret で構成されます。静的認証情報を使用すると、多くのリスクが生じます。たとえば、開発者が静的な AccessKey をアプリケーションコードにハードコーディングし、GitHub などのパブリックリポジトリにアップロードする可能性があります。これにより AccessKey が漏洩し、ビジネス上の損失につながる可能性があります。Alibaba Cloud では、可能な限りロールの偽装を通じて一時的な認証情報であるセキュリティトークンサービス (STS) トークンを取得する必要があります。静的な AccessKey の代わりにこのトークンを使用します。STS トークンは、ロールの最大セッション期間 (時間単位で測定) が経過すると自動的に有効期限が切れます。これにより、静的認証情報の漏洩によるリスクが大幅に軽減されます。
Alibaba Cloud は、さまざまな種類のクラウドアプリケーションのデプロイメントに対して STS トークン認証情報の使用を統合する機能を提供します。
ECS インスタンスにデプロイされたアプリケーションの場合、インスタンス RAM ロールを使用できます。インスタンスに RAM ロールをアタッチすると、アプリケーションは インスタンスメタデータサービスを介して一時的な権限付与トークンを取得 できます。
ACK にデプロイされたアプリケーションの場合、RRSA 機能を使用 して RAM ロールを指定された ServiceAccount に関連付けることができます。これにより、Pod レベルで対応するロールを偽装して STS トークンを取得できます。
Function Compute にデプロイされたサーバーレスアプリケーションの場合、関数が属するサービスに他の Alibaba Cloud サービスへのアクセス権限を付与して STS トークンを取得できます。
デプロイメント方法に関係なく、アプリケーションコードで公式の Alibaba Cloud ソフトウェア開発キット (SDK) を使用できます。デプロイメントタイプに基づいて認証情報構成を設定することで、認証情報キャッシングや有効期限更新の特定のロジックを管理する必要なく、STS トークンを簡単に取得できます。