Cloud de Confiance by S3NS API とサービスを操作する前に、自分が誰であるかを証明する必要があります。この身元確認のプロセスを「認証」と呼びます。
Cloud de Confiance by S3NSに対して認証を行うには、ID の証拠として認証情報を提供する必要があります。たとえば、サービスを使用するには、パスワードやワンタイム コードなどの認証情報を使用して認証を行う必要があります。
Cloud de Confiance by S3NS は、認証済みユーザーをプリンシパルとして参照します。 Cloud de Confiance by S3NS プロジェクトやストレージ バケットなどのリソースにアクセスしようとすると、 Cloud de Confiance by S3NSは、リクエストされたリソースに対するプリンシパルのアクセスレベルを確認します。このプロセスは認可と呼ばれ、Identity and Access Management(IAM)と呼ばれるシステムによって処理されます。
これらのコンセプトは、ユーザーに代わって自動タスクを実行するコード(ワークロード)にも適用されます。ワークロードは、ID を証明してプリンシパルとして認証するための認証情報を提供する必要があります。その後、 Cloud de Confiance by S3NS は、ワークロードがリクエストしたリソースに対するアクセスレベルを判断できます。
プリンシパルのタイプ
認証できるプリンシパルにはさまざまな種類があります。タスクの異なるステージや、異なる開発環境で、異なるプリンシパル タイプを使用することもできます。
主なプリンシパル タイプと、認証に必要な認証情報は次のとおりです。
ユーザー アカウント: 偶発的な管理タスク、 Cloud de Confiance by S3NS サービスの非プログラムによる構成、テスト、実験、オブザーバビリティなど、人間がインタラクティブな作業を行うための Google アカウントです。
パスワードやワンタイム コードなどのユーザー認証情報を使用して、ユーザー アカウントとして認証します。
サービス アカウント: ワークロードがサービスやリソースにアクセスするために使用できる、 Cloud de Confiance by S3NS 内部のアカウントです。通常、サービス アカウントとして直接認証することはありません。代わりに、サービス アカウントを Compute Engine VM などのリソースにアタッチするか、サービス アカウントの権限借用を使用します。
ほとんどのシナリオでは、有効期間の短いサービス アカウントの認証情報を使用してサービス アカウントを認証することをおすすめします。
フェデレーション ID: 外部 ID プロバイダのユーザー アカウントまたはサービス アカウントを参照する ID です。 Cloud de Confiance by S3NSでサポートされているフェデレーション ID には、次の 2 種類があります。
Workforce Identity 連携: 外部 ID プロバイダで管理されている ID を使用して、ユーザーが Cloud de Confiance by S3NS にログインできるようにします。組織ですでにシングル サインオン(SSO)が設定されている場合は、このタイプの ID を使用して Cloud de Confiance by S3NSの認証を行うことができます。
Workforce Identity 連携を使用するには、ID プロバイダが OpenID Connect(OIDC)または SAML 2.0 をサポートしている必要があります。
Workload Identity 連携: Cloud de Confiance by S3NS の外部で実行されているワークロードが Cloud de Confiance by S3NSリソースを操作できるようにします。
Workload Identity 連携は、X.509 クライアント証明書を使用して認証するワークロード、アマゾン ウェブ サービス(AWS)または Azure で実行されるワークロード、オンプレミスの Active Directory、GitHub や GitLab などのデプロイ サービス、OpenID Connect(OIDC)または Security Assertion Markup Language(SAML)V2.0 をサポートする任意の ID プロバイダで使用できます。
Cloud de Confiance by S3NSでサポートされているこれらのプリンシパル タイプとその他のプリンシパル タイプの詳細については、プリンシパル タイプをご覧ください。
認証用に Cloud de Confiance by S3NS 組織を構成する
Cloud de Confiance by S3NS 組織の認証を設定する際に、既存のシステムとワークフローを Cloud de Confiance by S3NSに統合する必要がある場合があります。
使用する既存の ID プロバイダがある場合は、Workforce Identity 連携を設定する必要があります。
Cloud de Confiance by S3NS リソースへのアクセスを必要とするワークロードが Cloud de Confiance by S3NS の外部で実行されている場合は、Workload Identity 連携を設定する必要があります。
Cloud de Confiance by S3NS環境のセキュリティを強化するために、次のことも行うことをおすすめします。
ユーザーに対して多要素認証が有効になっていることを確認します。
再認証の設定を変更する必要があるかどうかを確認します。
API キーの管理に関するポリシーを作成します。
サービス アカウント キーの管理に関するポリシーを作成します。
ユーザーとワークロードを認証する
Cloud de Confiance by S3NS に対する認証方法は、使用している API とサービス、およびそれらの API とサービスを操作する方法によって異なります。
人間を認証する
偶発的な管理タスク、リソースの設定、構成の変更、テスト、ログの閲覧などの手動の対話型作業を行う場合は、ユーザー アカウントの認証情報を使用して認証します。
コンソール
Cloud de Confiance コンソールでのインタラクティブな作業では、ユーザー認証情報を使用してウェブ インターフェースにログインすることで認証を行います。
Cloud de Confiance コンソール セッションと同じ認証情報が Cloud Shell で使用されます。ここで、gcloud CLI にアクセスできます。
gcloud
ローカル デバイスに gcloud CLI をインストールしたら、ターミナルで次のコマンドを実行して、ユーザー認証情報を使用して Cloud de Confiance by S3NS の認証を行うことができます。
gcloud auth login
認証後、後続の gcloud コマンドは、ログインしたプリンシパルを使用してリクエストを行います。
Workforce Identity 連携認証情報、Workload Identity 連携認証情報、またはサービス アカウント キーを使用して認証する場合は、gcloud CLI を使用して認証するをご覧ください。
ワークロードを認証する
ローカル デバイス、Cloud de Confiance by S3NS、オンプレミス、別のクラウドでコードを開発して実行する場合でも、ワークロードを認証する最も柔軟で移植性の高い方法は、アプリケーションのデフォルト認証情報(ADC)と呼ばれるメカニズムを使用して認証情報を提供することです。
ADC を実装するライブラリ(Cloud de Confiance by S3NS クライアント ライブラリなど)は、実行される環境内の既知の場所で認証情報を確認します。つまり、コードの実行場所を変更しても、コード自体を変更する必要はなく、その環境で使用される認証情報のみを変更すればよいということです。
たとえば、ローカルで開発する場合、ADC が認証にユーザー認証情報を使用するように環境を設定できます。コードが本番環境に対応したら、変更せずに Compute Engine VM インスタンスにデプロイし、代わりに有効期間の短いサービス アカウント認証情報を使用して認証を行うように環境を設定できます。
次のシナリオでは、ADC を使用して認証することはできません。
gcloud CLI を認証する場合。
API キーを使用する場合。API キーは特定の API でのみ使用できます。
特定の環境で ADC を設定する方法については、アプリケーションのデフォルト認証情報を設定するをご覧ください。
次のステップ
Cloud de Confiance by S3NSのさまざまな認証方法について学習する。
Cloud de Confiance by S3NSでプリンシパルがアクセスできるものを制御する方法については、認可とアクセス制御をご覧ください。