Identity and Access Management: Cloud Identity による認証
Google Cloud Japan Team
※この投稿は米国時間 2022 年 7 月 26 日に、Google Cloud blog に投稿されたものの抄訳です。
セキュリティには、アクセスを制御するための 3 つの「A」があります。認証（ユーザーは誰か）、承認（ユーザーは何を行えるか）、監査（ユーザーはどのような操作を行っているか）です。もう少し少し掘り下げて見てみましょう。
認証（AuthN）: 認証とは、確認用の非公開情報（たとえば、パスワード、証明書、鍵など）を使用してユーザーを識別するプロセスです。Google Cloud では、Cloud Identity により認証が行われます。
承認（AuthZ）: 認証のプロセスでは権限セットは提供されません。承認は、認証後にユーザーに割り当てる権限を設定するために使用されます。Google Cloud では、Cloud IAM を使用して承認が行われます（デフォルトで幅広い権限を持つ管理者ロールの割り当てには、Cloud Identity が使用されます）。
監査: 監査とは、特定の ID によってアクセスまたは修正されたリソースをモニタリングすることです。Google Cloud では、Cloud Audit Logging がリソースの監査に役立ち、Reports API が Cloud Identity のオペレーションの監査に役立ちます。ログを主要な SIEM システムに統合することもできます。
この投稿では、認証に焦点を当てて説明します。
Cloud Identity とは
Cloud Identity は、Google Cloud の ID プロバイダ（IdP）です。また、Google Workspace で利用されている Identity as a Service（IDaaS）ソリューションでもあります。Google Cloud ユーザーのデジタル ID を保存し管理することができます。Cloud Identity への移行時または使用開始時には、Google 管理コンソールから各ユーザーのアカウントを無料で作成できます。Cloud Identity（無償版）には 50 ユーザーまでの制限があるため、お客様は Cloud Identity Premium（有料サブスクリプション）を購入するか、CI の無償版のライセンスの追加を申請（正当な理由に基づいて実施）することが可能です。また、Cloud Identity は、ユーザー ライフサイクル管理、アカウントのセキュリティ、シングル サインオン（SSO）をサポートしています。
Cloud Identity の設定は、組織が Google Cloud を導入するうえでの前提条件です。その仕組みは次のとおりです。
Cloud Identity インスタンスを設定すると、所有するドメインを追加するよう求められます（通常は企業のメインのドメイン）。
このドメインを所有していることを証明するよう求められます。これは通常、TXT レコードを DNS レコードに追加することで行います。
ドメインの所有権を証明したら、ドメインと同じ名前で Google Cloud の組織が作成され、Google Cloud を使用できるようになります。
Cloud Identity と Google Cloud を連携させる方法
ID を Cloud Identity にインポートするには、手動、CSV ファイル経由、API やサードパーティの IdP システムを使用するなど、さまざまな方法があります。設定が完了すると、ユーザーとグループは Cloud IAM によって使用され、Google Cloud のリソースへのアクセスが付与されます。ここで重要なのは、Cloud Identity ロールはユーザーやグループを管理するために使用され、クラウド リソースに対する権限を管理する Google Cloud IAM ロールとは異なるということです。この違いについては、Cloud IAM 承認に関する別の投稿で詳しく説明します。
認証のオプション
ユーザー名とパスワード以外にも、よく使用される認証オプションが 2 つあります。
Google 認証システムによる 2 段階認証プロセス（2SV）
2 段階認証プロセスでは、ユーザー名とパスワードに加え、第 2 の認証要素を追加します。ただし、すべての 2 段階認証プロセスの方式が同じというわけではなく、SMS、バックアップ コード、ワンタイム パスワード（OTP）、モバイルのプッシュ通知は保護を強化しますが、フィッシング攻撃を受ける可能性はまだあります。FIDO Universal 2nd Factor（U2F）セキュリティ キーには高いフィッシング耐性があります。U2F プロトコルは、暗号化を使用して、ユーザーの本人確認とアクセス先のウェブサイトの URL を確認します。キーはデバイスに維持されているため、サーバー側の共有シークレットを盗むことができず、フィッシング、中間者攻撃、リプレイ攻撃から保護することができます。
セキュリティの確保において、Google はセキュリティ キーを推奨しています。さらに、最適なセキュリティのために、管理者にとってセキュリティ キーの使用は必須のものと考える必要があります。Google では、Google によって設計されたキーの完全性を検証する特別なファームウェアが組み込まれている Titan セキュリティ キーを提供しています。また、Android や iOS デバイスもセキュリティ キーとして使用できます（Bluetooth が必要）。Titan セキュリティ キーは FIDO U2F プロトコルを採用しているため、Google からのメッセージ経由でログインするのと同様のユーザー エクスペリエンスを提供しながら、より強固な保護を実現します。
Cloud Identity は、サードパーティの IdP（Azure AD や Okta など）による 2 段階認証プロセスの要求も可能です。たとえば、この場合、ユーザーがパスワードを入力して Azure AD にログインし、IdP（Azure AD）と Google との間で SAML 交換が成功した後に、追加の認証ステップとして Google の 2 段階認証プロセス方式を利用できます。SAML SSO 後の認証は静的ではなく（例: 毎回確認されるわけではない）、リスクベースです。
サードパーティ ID プロバイダによる SSO 認証
SSO を使用した認証を、Okta、Ping、Active Directory フェデレーション サービス（AD FS）、Azure AD などのサードパーティの SAML 2.0 ID プロバイダに委任することもできます。この方法は通常、すでに互換性のある IdP を使用している場合、Google Cloud のオンボーディングを迅速化し、混乱を抑えることができます。
今回は、Google Cloud における認証のオプションの全体像について説明しました。ユーザーが認証された後は、実行したい操作を行うための承認が必要となります。Cloud IAM による承認について詳しくは、こちらをご覧ください。Cloud Identity の詳細については、ドキュメントをご確認ください。
#GCPSketchnote をさらにご覧になるには、GitHub リポジトリをフォローしてください。同様のクラウド コンテンツについては、Twitter で @pvergadia をフォローしてください。thecloudgirl.dev もぜひご覧ください。
- Google、デベロッパー アドボケイト リード Priyanka Vergadia
