IAP の再認証

IAP の再認証を使用すると、サービスとアプリケーションのオーナーまたは Google Cloud 管理者は、認証済みのエンドユーザーに対し、IAP で保護されたサービスまたはアプリケーションへのアクセス時に指定された時間が経過した後に、再認証を義務付けることができます。IAP で保護されたサービスまたはアプリケーションへユーザーがアクセスできる期間を制限し、これが過ぎるとユーザーは再度認証を求められます。

IAP 再認証は、IAP で保護されたサービスとアプリケーションに再認証ポリシーを適用するように設計されています。機密情報を処理する重要なサービスやアプリケーションでは、このように設定することをおすすめします。たとえば、重要な人事アプリケーションにアクセスするユーザーが、第 2 要素を使用して 1 時間ごとに再認証するように指定できます。

サポートされている再認証方法

再認証の設定は、次の方法で管理できます。

ログイン: IAP は保護されたアプリケーションの再認証を強制し、ユーザーは再ログインする必要があります。
セキュリティキー: エンドユーザーは、設定したセキュリティキーベースの 2 要素認証を使用して再認証する必要があります。
登録済みの 2 要素: エンドユーザーは、登録済みの 2 段階認証プロセスのいずれかを使用して再認証する必要があります。

詳しくは、IapSettings をご覧ください。

再認証ポリシーの設定

reauthSettings は IapSettings の一部であるため、リソース階層内の任意のリソースタイプに設定できます。制限を適用するには、組織、フォルダ、プロジェクト、サービスレベルでサービスまたはアプリケーションに reauthSettings を設定します。たとえば、組織内のすべてのアプリケーションまたは特定のアプリケーションに対して、セッションの長さを最大 1 時間に制限できます。

再認証の設定に使用できるポリシータイプは 2 つあります。

最小: リソース（組織など）でポリシータイプが MINIMUM に設定されている場合、これより下位レベルのリソース（フォルダなど）の再認証設定を評価すると、2 つの設定が結合されます。下位レベルのリソースに再認証の設定がない場合、結合結果は上位レベルのリソースの空でない設定になります。それ以外の場合は、2 つのリソースのうちのセッション継続時間が短く、再認証方法の優先度の高い方が結合で使用されます。ポリシーのタイプは常に MINIMUM です。結合された再認証の設定は、次の下位レベルのリソース（プロジェクトなど）の再認証設定と結合するために使用されます。

サポートされている 3 つのメソッドは、優先度の高い方から Secure key、Enrolled second factors、Login の順でネストされます。
デフォルト: リソース（組織など）でポリシータイプが DEFAULT に設定されている場合、これより下位レベルのリソース（フォルダなど）の再認証設定を評価するときに、下位レベルのリソース設定が使用されます（構成されている場合）。それ以外の場合は、上位レベルのリソースの再認証設定が適用されます。

どちらのポリシータイプでも、評価プロセスが繰り返され、ターゲットのサービスまたはアプリケーションの reauthSettings が決定されます。次の例は、評価前と評価後の設定を示しています。評価中に、フォルダと組織 reauthSettings が結合され、フォルダのポリシータイプが MINIMUM に変更されます。その後、結合された設定を使用して、サービスまたはアプリケーション reauthSettings と結合します。

組織IapSettings:

accessSettings:
  reauthSettings:
    method: "ENROLLED_SECOND_FACTORS"
    maxAge: "3600s"
    policyType: "MINIMUM"

フォルダIapSettings:

accessSettings:
  reauthSettings:
    method: "LOGIN"
    maxAge: "1200s"
    policyType: "DEFAULT"

サービスまたはアプリケーション IapSettings:

accessSettings:
  reauthSettings:
    method: "SECURE_KEY"
    maxAge: "7200s"
    policyType: "DEFAULT"

結合後の設定:

組織IapSettings:

accessSettings:
  reauthSettings:
    method: "ENROLLED_SECOND_FACTORS"
    maxAge: "3600s"
    policyType: "MINIMUM"

フォルダIapSettings:

accessSettings:
  reauthSettings:
    method: "ENROLLED_SECOND_FACTORS"
    maxAge: "1200s"
    policyType: "MINIMUM"

サービスまたはアプリケーション IapSettings:

accessSettings:
  reauthSettings:
    method: "SECURE_KEY"
    maxAge: "1200s"
    policyType: "MINIMUM"

この例では、すべてのリソースのポリシータイプが DEFAULT に設定されている場合に、サービスまたはアプリケーションの reauthSettings が使用されます。

MaxAge

MaxAge パラメータを使用して、エンドユーザーが再認証を行う頻度を秒単位で指定します。たとえば、1 時間の再認証ポリシーを設定するには、次の例のように秒単位を 3600 に設定します。

accessSettings:
  reauthSettings:
    method: "LOGIN"
    maxAge: "3600s"
    policyType: "MINIMUM"

maxAge の最小値は 5 分です。

再認証ポリシーを設定するには、次の操作を行います。

コンソール

[Identity-Aware Proxy] ページに移動します。
[Identity-Aware Proxy] ページに移動
プロジェクトを選択し、再認証ポリシーを設定するリソースを選択します。
リソースの [設定] を開き、[再認証ポリシー] で [再認証を構成する] を選択します。
再認証の設定を指定し、[保存] をクリックします。

gcloud

組織レベル、プロジェクトレベル、フォルダレベルで、リソースとサービスに対して再認証ポリシーを設定できます。再認証ポリシーを設定するコマンドの例を次に示します。

詳細については、gcloud iap settings set をご覧ください。

次のコマンドを実行します。

gcloud iap settings set SETTING_FILE [--organization=ORGANIZATION --folder=FOLDER --project=/PROJECT --resource-type=RESOURCE_TYPE --service=SERVICE --version=VERSION

組織内のリソースに再認証ポリシーを設定するには、次のコマンドを実行します。

gcloud iap settings set SETTING_FILE --organization=ORGANIZATION

フォルダ内のリソースに再認証ポリシーを設定するには、次のコマンドを実行します。

gcloud iap settings set SETTING_FILE --folder=FOLDER

プロジェクト内のすべてのウェブタイプリソースに再認証ポリシーを設定するには、次のコマンドを実行します。

gcloud iap settings set SETTING_FILE --project=PROJECT --resource-type=iap_web

プロジェクト内の App Engine サービスに再認証ポリシーを設定するには、次のコマンドを実行します。

gcloud iap settings set SETTING_FILE --project=PROJECT --resource-type=app-engine --service=SERVICE

ここで、SETTING_FILE は次のようになります。

accessSettings:
  reauthSettings:
    method: "LOGIN"
    maxAge: "3600s"
    policyType: "MINIMUM"

以下を置き換えます。

FOLDER: フォルダ ID。
ORGANIZATION: 組織 ID。
PROJECT: プロジェクト ID。
RESOURCE_TYPE: IAP リソースタイプ。app-engine、iap_web、compute、organization、またはfolder にする必要があります。
SERVICE: サービス名。resource-type が compute または app-engine の場合、これは省略可能です。
VERSION: バージョン名。これは compute には適用されず、resource-type が app-engine の場合は省略可能です。

API

次のコマンドを実行して iap_settings.json ファイルを準備します。必要に応じて値を更新します。

cat << EOF > iap_settings.json
{
  "access_settings": {
      "reauth_settings": {
            "method": "LOGIN",
            "maxAge": "300s",
            "policy_type": "DEFAULT"
        }
    }
}
EOF

gcloud iap settings get コマンドを実行してリソース名を取得します。出力から名前フィールドをコピーします。次のステップで名前が必要になります。

gcloud iap settings get [--organization=ORGANIZATION --folder=FOLDER --project=/PROJECT --resource-type=RESOURCE_TYPE --service=SERVICE --version=VERSION]

次のコマンドの RESOURCE_NAME は、前の手順の名前に置き換えます。IapSettings が更新されます。

curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d @iap_settings.json \
"https://iap.googleapis.com/v1/RESOURCE_NAME:iapSettings?updateMask=iapSettings.accessSettings.reauthSettings"

再認証の認証情報について

再認証に成功すると、IAP はエンドユーザーのブラウザに Cookie を作成します。類似したアプリの使用時に頻繁に再認証が行われないようにするため、Cookie は最上位のプライベートドメインに設定され、そのプライベートドメイン全体で有効になります。

たとえば、foo.example.com は IAP で保護されたリソースで、IAP 再認証ポリシーを持ちます。再認証に成功すると、IAP は、最上位のプライベートドメインである example.com に Cookie を設定します。bar.example.com などの同じ最上位のプライベートドメインのアプリは、同じ再認証の認証情報を使用します。認証情報が有効であれば、ユーザーに再認証を求めるメッセージは表示されません。

myapp.appspot.com のような URL の場合、appspot.com はパブリックドメインであるため、最上位のプライベートドメインは myapp.appspot.com になります。

既知の制限事項

再認証はブラウザフローでのみサポートされています。プログラムによるユーザーアカウントへのアクセスはサポートされていません。たとえば、モバイルアプリやデスクトップアプリでは、再認証を必要とするリソースにアクセスできないため、ユーザーを再認証する方法はありません。
サービスアカウントと IAP-TCP は、再認証の要件から除外されます。
再認証は、IAM メンバータイプ allUsers では機能しません。
再認証を必要とするリソースにアクセスできないため、再認証では Identity Platform を介した外部 ID はサポートされていません。