UID2 Private Operator for AWS Integration Guide

UID2 Operator は、UID2 エコシステムにおける API サーバーです。AWS Marketplace で稼働する Private Operator Service の場合、UID2 Operator ソリューションはAWS Nitro Enclave テクノロジーで強化されています。これは、UID2 情報を不正なアクセスから保護するための追加のセキュリティ対策です。

UID2 Private Operator for AWS

注記

UID2 Private Operator for AWS は無償製品です。製品ページに表示されている費用は、必要なインフラの概算費用となります。

UID2 Private Operator for AWS を契約することで、以下を利用できます:

• Amazon Machine Image (AMI) UID2 Operator Service がインストールされ、ブートストラップの準備が整っている状態です:
  AMI には、UID2 Operator Service がすでにセットアップされた Amazon Linux 2023 オペレーティングシステムが含まれています。AMI をベースにした EC2 インスタンスが起動すると、AWS アカウントから設定を自動的に取得し、エンクレーブ内で UID2 Operator サーバーを起動します。
• CloudFormation template:
  このテンプレートでは、UID2 Operator AMI がデプロイ展開されます。

Prerequisites

AWS で 1 つまたは複数の UID2 Operator をサブスクライブしてデプロイするには、次の手順を実行します:

1. UID2 Operator としてあなたの組織を登録します。
2. 最小限の権限 を持つIAMロールで AWS アカウントを作成します。

Minimal IAM Role Privileges

ワンクリックデプロイを成功させるためには、AWS アカウントに以下のアクションを実行する権限が必要です:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "kms:*",
        "autoscaling:*",
        "cloudformation:*",
        "iam:ListRoleTags",
        "secretsmanager:*",
        "iam:PutRolePolicy",
        "iam:AddRoleToInstanceProfile",
        "iam:ListRolePolicies",
        "iam:ListPolicies",
        "iam:GetRole",
        "iam:GetPolicy",
        "iam:DeleteRole",
        "iam:UpdateRoleDescription",
        "iam:TagPolicy",
        "iam:GetRolePolicy",
        "iam:CreateInstanceProfile",
        "iam:UntagRole",
        "iam:TagRole",
        "iam:ListInstanceProfilesForRole",
        "iam:PassRole",
        "iam:DeleteRolePolicy",
        "iam:ListPolicyTags",
        "iam:DeleteInstanceProfile",
        "iam:ListRoles",
        "iam:CreatePolicy",
        "iam:UntagPolicy",
        "iam:UpdateRole",
        "iam:UntagInstanceProfile",
        "iam:TagInstanceProfile",
        "iam:SetDefaultPolicyVersion",
        "iam:UpdateAssumeRolePolicy",
        "iam:GetPolicyVersion",
        "iam:RemoveRoleFromInstanceProfile",
        "iam:CreateRole",
        "iam:AttachRolePolicy",
        "iam:DetachRolePolicy",
        "iam:ListAttachedRolePolicies",
        "iam:DeletePolicy",
        "iam:ListInstanceProfileTags",
        "iam:CreatePolicyVersion",
        "iam:GetInstanceProfile",
        "iam:ListInstanceProfiles",
        "iam:ListPolicyVersions",
        "iam:DeletePolicyVersion",
        "iam:ListUserTags"
      ],
      "Resource": "*"
    }
  ]
}

Resources Created

次の表は、deployment 中に作成されるすべてのリソースの一覧です。

Name	Type	Description
KMSKey	AWS::KMS::Key	秘密暗号化用のキー (設定文字列用) です。
SSMKeyAlias	AWS::KMS::Alias	KMSキーに簡単にアクセスする方法を提供するエイリアスです。
TokenSecret	AWS::SecretsManager::Secret	Operator Key を含む暗号化されたコンフィギュレーションです。
WorkerRole	AWS::IAM::Role	UID2 Operator が実行する IAM ロールです。ロールは、設定キーへのアクセスを提供します。
WorkerInstanceProfile	AWS::IAM::InstanceProfile	Operator EC2 インスタンスにアタッチする Worker Role を持つインスタンスプロファイルです。
SecurityGroup	AWS::EC2::SecurityGroup	オペレーターインスタンスに対するルールを提供するセキュリティグループポリシーです。Security Group Policy を参照してください。
LaunchTemplate	AWS::EC2::LaunchTemplate	すべての設定が配置された起動テンプレートです。このテンプレートから新しい UID2 Operator インスタンスを起動できます。
AutoScalingGroup	AWS::AutoScaling::AutoScalingGroup	起動テンプレートがアタッチされている Auto Scaling Group(ASG)。必要であれば、これを使用して後でインスタンスの必要数を更新できます。

Customization Options

以下は、デプロイ の実行中または実行後にカスタマイズできる内容です。

• VPC: 既存の VPC と関連する VPC サブネット ID を指定する必要があります。
• ルートボリュームサイズ (8G Minimum)
• SSH キー: UID2 Operator の EC2 インスタンスにアクセスする際に使用する SSH キーです。
• Instance type: m5.2xlarge、m5.4xlarge、といった具合です。カスタマイズがない場合は、デフォルト値の m5.2xlarge を推奨します。

Security Group Policy

注記

ドメインに関連する証明書をエンクレーブに渡すのを避けるため、HTTPS の代わりにインバウンド HTTP が許可されています。これは、組織内部のプライベートネットワークで使用する場合、セキュアレイヤーのコストを回避することにもなります。

Port Number	Direction	Protocol	Description
80	Inbound	HTTP	Healthcheck エンドポイント /ops/healthcheck を含むすべての UID2 API を提供します。 すべてが稼働している場合、エンドポイントは HTTP 200 を返し、レスポンスボディは OK となります。詳しくは、Checking UID2 Operator Status を参照してください。
9080	Inbound	HTTP	Prometheus metrics サービス (/metrics)。
443	Outbound	HTTPS	UID2 Core Service を呼び出し、オプトアウトデータとキーストアを更新します。

VPC Chart

次の図は、Private Operator をホストする仮想プライベートクラウドを示したものです。

Deployment

UID2 Operator を AWS Marketplace にデプロイするには、以下の手順を実行します:

1. Unified ID 2.0 Operator on AWS Marketplace をサブスクライブします。AWS がサブスクライブが完了するまで数分かかる場合があります。

2. Configuration をクリックし、構成値を指定します。

   ソフトウェアバージョンについては、Operator Version を参照し、AWS Version 列で値を選択します。

3. Configuration ページで Launch をクリックし、Launch CloudFormation アクションを選択します。

4. スタック作成ウィザードでテンプレートを指定し、Next をクリックします。テンプレートファイルの S3 パスが自動的に入力されます。

5. スタックの詳細 を入力し、Next をクリックします。

6. スタックのオプション を設定し、Next をクリックします。

7. 入力した情報を確認し、必要に応じて変更します。

8. IAM ロールを作成する許可が求められた場合は、I acknowledge that AWS CloudFormation might create IAM resources チェックボックスを選択します。

9. Create stack をクリックします。

スタックの作成には数分かかります。Auto Scaling Group (ASG) が作成されたら、選択して EC2 インスタンスを確認できます。デフォルトでは、最初は 1 つのインスタンスのみが起動します。

Operator Version

最新の ZIP ファイルは、次の表の Release Notes 欄にリンクされています。

Release	Version	Date	Release Notes	AWS Version	GCP Download	Azure Download
Q1 2024	5.26.19	February 13, 2024	v5.26.19-56899dc0d7	5.26.19-56899dc0d7	5.26.19-56899dc0d7 GCP ZIP	5.26.19-56899dc0d7 Azure ZIP
Q2 2024	5.37.12	June 12, 2024	v5.37.12	5.37.12	gcp-oidc-deployment-files-5.37.12.zip	azure-cc-deployment-files-5.37.12.zip
Q3 2024	5.38.104	September 12, 2024	v5.38.104	5.38.104	gcp-oidc-deployment-files-5.38.104.zip	azure-cc-deployment-files-5.38.104.zip
Q3 2024 Out-of-band	5.41.0	October 29, 2024	v5.41.0	5.41.0	gcp-oidc-deployment-files-5.41.0.zip	azure-cc-deployment-files-5.41.0.zip

Stack Details

以下の画像は、スタックの作成ウィザード (デプロイ Step 5) のSpecify stack detailsページを示しています。次の表は、パラメータ値のリファレンスを提供します。

下段です:

次の表は、デプロイ の Step 5 で指定するパラメータ値について説明したものです。

Parameter	Description
Stack name	好きな名前をつけてください。
OPERATOR_KEY	UID2 Admin チームから受け取った Operator Key です。
UID2 Environment	本番環境なら prod、インテグレーションインテグレーション環境なら integ を選択します。
Instance Type	m5.2xlarge を推奨します。
Instance root volume size	15GB 以上を推奨します。
Key Name for SSH	デプロイされた EC2 インスタンスに SSH アクセスするための EC2 キーペアです。
Trusted Network CIDR	CIDR (Classless Inter-Domain Routing) 値は、オペレーターサービスにアクセスできる IP アドレス範囲を決定します。 UID2 オペレーターへのアクセスを制限して、内部ネットワークまたはロードバランサーからのみアクセスできるようにするには、CIDR 値として内部 IP 範囲を指定します。
VPC	既存の VPC ID。
VpcSubnet1	既存の VPC AZ1 サブネット ID。
VpcSubnet2	既存の VPC AZ2 サブネット ID。

Stack Configuration Options

次の図は、スタックの作成ウィザード (Deployment Step 6) のスタックオプションの設定ページを示しています。

次の表は、Deployment の Step 6 で指定するパラメータ値について説明したものです。

Parameter	Description
Tags	(オプション) スタックにタグをつけます。
Permissions	AWS Marketplace にサブスクライブする IAM ロールとスタックをデプロイする IAM ロールが分かれている場合、スタックをデプロイするために使用するロールの名前/ARN を入力します。
Stack failure options	デプロイメントに失敗したときの処理を選択します。Roll back all stack resources (すべてのスタックリソースをロールバックする) オプションを推奨します。
Advanced options	これらはオプションです。

Creating a Load Balancer

ロードバランサーとターゲットオペレーターのオートスケーリンググループを作成するには、次の手順を実行します:

1. AWS コンソールで EC2 ダッシュボードに移動し、Load Balancer を検索します。
2. Create Load Balancer をクリックします。
3. Load balancer typesページの Application Load Balancer セクションで、Create をクリックします。
4. UID2 Load balancer name を入力します。パブリックインターネットから UID2 API にアクセスする必要があるかどうかに応じて、Internet-facing または Internal スキームを選択します。
5. ターゲットの VPC と、CloudFormationスタックで使用する少なくとも2つのサブネットを選択します。
6. Security groups の下にある Create new security group をクリックし、以下を実行します:
   1. UID2SGALB を Security group name として入力し、関連する Description も入力します。
   2. Inbound rules の下で、Add rule をクリックし、要件に応じて HTTPS タイプと適切な Source を選択します。
   3. Create security group をクリックします。
7. ロードバランサーのページに戻り、新しく作成した UID2SGALB セキュリティグループを選択します。
8. Listeners and routing の下にある、Create target group リンクをクリックし、以下を実行します:
   1. Specify group details page で、ターゲットタイプとして Instances を選択し、 Target group name として UID2ALBTG を入力します。
   2. Protocol version として HTTP1 が選択されていることを確認します。
   3. Health checks の下で、Health check path に /ops/healthcheck を指定し、Next をクリックします。
   4. オートスケーリンググループが作成した UID2 Operator EC2 インスタンスを選択し、Include as pending below をクリックします。
   5. ターゲットのすべてのポートに 80 が含まれていることを確認します。
   6. Create target group をクリックします。
9. ロードバランサーのページに戻り、Listeners and routing の下にある、UID2ALBTG をデフォルトのアクションとして転送するターゲットグループとして選択します。新しく作成したターゲットグループが表示されるように、ターゲットグループをリフレッシュする必要があるかもしれないことに注意してください。リスナーの Port を 443 に変更します。
10. AWS user guide の指示に従って、HTTPS リスナーをセットアップします。
11. Create load balancer をクリックします。
12. ロードバランサーのステータスを確認するには、以下のセクションに進んでください: Checking UID2 Operator Status

Checking UID2 Operator Status

ロードバランサー配下の UID2 Operator のステータスを確認するには、次の手順を実行します:

1. EC2 > Load balancers で、ロードバランサーの DNS name 列を見て、ロードバランサーの DNS 名を特定します。
2. ブラウザで、https://{dns-name-of-your-load-balancer}/ops/healthcheck にアクセスします。OK のレスポンスであれば、Operator のステータスは良好です。

When a Private Operator fails to attest with the Core service, one of the following actions happens:

• HTTP 401 response. The Private Operator terminates itself immediately.
  • Likely Causes: API key revoked or incorrect.
• Any other non-200 response code. The Private Operator continues to function for 12 hours. If the issue is not resolved in this time frame, it terminates itself.
  • Likely Causes: Core service issues, network issues.

Private Operator hosts must have infrastructure in place to handle alerting and restarting operators in the case of an error.

Upgrading the UID2 Operator

各オペレーターのバージョンを更新するたびに、Private Operator は、アップグレードのウィンドウを持つメール通知を受け取ります。アップグレードウィンドウの後、古いバージョンは非アクティブ化され、サポートされなくなります。

ここでは、アップグレードについて紹介します:

• 新しいバージョンの提供に関する情報は、UID2 Operator on AWS Marketplace のページで提供されます。
• UID2 Operator をアップグレードするには、新しい CloudFormation スタックを作成します。詳しくは、デプロイ を参照してください。

ヒント

スムーズな移行を行うには、まず新しいスタックを作成します。新しいスタックが起動し、サービスを提供する準備ができたら、古いスタックを削除してください。ロードバランサーを使用している場合は、まず新しいインスタンスを立ち上げて実行してから、DNS 名を以前のものから新しいものに変換してください。

Managing the Logs

以下のセクションは、ログを最大限に活用するためのヒントを提供します:

• Where to Read Logs
• Default Log Settings
• Changing the Log Rotation Schedule
• Additional Commands for Logging

Where to Read Logs

ログにアクセスするには、EC2 インスタンスに SSH でログインします。ログは /var/logs/ にあり、operator.log-<timestamp rotated> の形式です。

Default Log Settings

UID2 system はログの生成に syslog-ng を使用し、ログのサイズが過大にならないようにログのローテーションと管理を行うために logrotate と cron ジョブを使用しています。以下のセクションでは、デフォルト設定とその背後にある理由について説明し、特定の要件に合わせてログローテーション設定をカスタマイズするためのガイダンスを提供します:

• Log Rotation Configuration
• Log Rotation Default Settings
• cronjob Configuration

Log Rotation Configuration

Operator インスタンスがデプロイされると、デフォルトのログローテーション設定が適用されます:

• ログは毎日ローテーションされ、30個のログエントリが保持されるため、ログ履歴はログエントリが異常に大きくない限り30日分のデータに相当します。
• ログエントリが非常に大きい場合、ログサイズが24時間以内に30MBに達した場合、その時点でログがローテーションされます。

Log Rotation Default Settings

以下はデフォルトの logrotete の設定です。/etc/logrotate.d/operator-logrotate.conf に定義されています:

/var/log/operator.log*
{
        rotate 30
        daily
        maxsize 30M
        dateext dateformat -%Y-%m-%d-%s
        notifempty
        sharedscripts
        postrotate
                /usr/sbin/syslog-ng-ctl reload
        endscript
}

この設定の詳細は logrotate(8) - Linux man page を参照するか、Linux 環境で man logrotate を実行してください。

cronjob Configuration

logrotate は、デフォルトで /etc/cron.daily に次のスクリプトを生成します:

#!/bin/sh
   
/usr/sbin/logrotate -s /var/lib/logrotate/logrotate.status /etc/logrotate.conf
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
    /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit 0

The following script in /etc/cron.d ensures that the logrotate check is run every minute:

# Run the minutely jobs
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
* * * * * root /usr/sbin/logrotate -s /var/lib/logrotate/logrotate.status /etc/logrotate.conf

これらはデフォルト設定です。以下はその理由です:

• スクリプトは maxsize 条件が頻繁にチェックされるようにします。
• コマンドは /var/lib/logrotate/logrotate.status を参照してログのステータスをチェックし、ログがローテーション条件に達したかどうかを確認して、logrotate が毎分実行されたときにも余分なローテーションが行われないようにします。

Changing the Log Rotation Schedule

ログローテーションスケジュールを変更するには、/etc/logrotate.d/uid2operator.conf ファイルを更新します。

logrotate のドキュメントに従って指示に従ってください: logrotate(8) - Linux man ぺージを参照してください。

注記

変更を反映するためにサービスを再起動する必要はありません。

Additional Commands for Logging

次の表は、ログを管理するために役立つ追加のコマンドを示しています。

Action	Command
何がローテーションされるかの詳細を提供します。	sudo logrotate -f /etc/logrotate.conf --debug
スケジュールされた間隔を変更することなく、手動で logrotate を1回実行します。	sudo logrotate -f /etc/logrotate.conf --force
syslog-ng をリロードします。	sudo /usr/sbin/syslog-ng-ctl reload

Technical Support

製品のサブスクリプションやデプロイに問題がある場合は、contact us にお問い合わせください。