
## Amazon Connect の緊急管理者ログインをリアルタイムに検知してみたい背景

Amazon Connect には「緊急管理者ログイン」というログイン方法があります。
「緊急管理者ログイン」についてドキュメントでは以下のように記載しています。

[緊急管理者ログイン \- Amazon Connect](https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/emergency-admin-login.html)

> ただし、緊急の場合は、AWS アカウントの認証情報を使用して Amazon Connect コンソールからログインできます。例えば、次のような場合は、この方法でログインする必要があります。
> ・ Amazon Connect 管理者パスワードを忘れてしまい、リセットする他の Amazon Connect 管理者がいない場合。
> ・ 誰かが誤って Amazon Connect 管理者 セキュリティプロファイルを削除した場合。
> ...
> 重要
> 毎日使用する場合は、常にインスタンス URL を使用してログインすることを強くお勧めします。この記事で説明する手順は、インスタンス URL の使用がオプションではない場合に、緊急アクセスにのみ使用してください。

上記の記述のように、緊急時のみに利用するログイン方法となっています。
一方で、管理者権限を有しているので、悪用されると大変なことになります。

Amazon Connect にはログイン/ログアウトレポート機能があり、こちらでエージェントによるログイン/ログアウトだけでなく、「緊急管理者ログイン」によるログイン/ログアウトも確認が可能です。
しかし、「緊急管理者ログイン」のリアルタイムな検知には向かないため、別の方法がないか調べてみました。

## Amazon Connect の緊急管理者ログインをリアルタイムに検知するにはどうすればいいか

### Amazon Connect エージェントイベントストリームを使う

Amazon Connect には「Amazon Connect エージェントイベントストリーム」という Amazon Connect インスタンス内のエージェントによるアクティビティを Amazon Kinesis Data Streams に配信する機能です。
「Amazon Connect エージェントイベントストリーム」についてドキュメントでは以下のように記載しています。

[Amazon Connect エージェントのイベントストリーム \- Amazon Connect](https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/agent-event-streams.html)

> Amazon Connect エージェントのイベントストリームは、Amazon Connect インスタンス内のエージェントによるアクティビティを、ほぼリアルタイムでレポートするための Amazon Kinesis のデータストリームです。ストリームに発行されたイベントには、次の CCP イベントが含まれます。
> ・ エージェントのログイン
> ・ エージェントのログアウト
> ・ エージェントが問い合わせに接続する
> ・ エージェントのステータスの変更 (問い合わせに対応できる [使用可能]、[休憩中] または [トレーニング] など）。

上記の記述には、「エージェントのログイン/ログアウト」と「緊急管理者ログイン」については明記されていませんが、検証してみたところ、「緊急管理者ログイン」のログイン/ログアウトに関しても配信されることを確認できました。

後は、Amazon Connect エージェントイベントストリーム を Kinesis Data Streams に配信する設定を行い、コンシューマーとして、EventType\:LOGIN を検出した場合に通知を行うようなアプリケーションを Lambda などで構築することで「緊急管理者ログイン」のリアルタイム検知が可能になります。

```json fn=緊急管理者ログイン時のデータ
{
    "AWSAccountId": "126721485485",
    "AgentARN": "arn:aws:connect:ap-northeast-1:xxxxxxxxxxx:instance/xxxxxxx-yyyy-zzzz-wwww-1111111111/agent/5da9e1aa-1234-45cb-asdf-4b2fdsa5af2e",
    "CurrentAgentSnapshot": {
        ...
    },
    "EventId": "3e00cbd8-xxxx-xxxx-xxxx-e4329a6e907b",
    "EventTimestamp": "2021-12-22T03:26:20.146Z",
    "EventType": "LOGIN",
    "InstanceARN": "arn:aws:connect:ap-northeast-1:xxxxxxxxxxx:instance/xxxxxxx-yyyy-zzzz-wwww-1111111111",
    "PreviousAgentSnapshot": {
       ...
    },
    "Version": "2017-10-01"
}
```

## Amazon Connect の緊急管理者ログインをリアルタイムに検知する　おまけ

「緊急管理者ログイン」の検証時に CloudTrail のログを確認したらそれらしいログが記録されていることが確認できました。

- `eventName` が `AdminGetEmergencyAccessToken` のログの件数と、ログイン/ログアウトレポートの結果の件数が一致することを確認済み。
- ログアウトを示すログはなかった。ログアウト自体 Amazon Connect Instace 側でやっているから CloudTrail に出ないのかも。
- 通常のエージェントのログインを示すようなログは確認できなかった。ログイン URL が Amazon Connect Instace 側だから CloudTrail に出ないのかも。

```json fn=緊急ログインと思われるログ
{
  "eventVersion": "1.08",
  "userIdentity": {
    ...
  },
  "eventTime": "2021-10-22T01:20:48Z",
  "eventSource": "connect.amazonaws.com",
  "eventName": "AdminGetEmergencyAccessToken",
  ...
}
```


Amazon Connect の緊急管理者ログインをリアルタイムに検知する


## クロスアカウントの CloudTrail ログを特定のアカウントの S3 バケットに保存する理由

AWS ブログでは AWS Organizations における組織単位のベストプラクティスについて以下のように記載しています。

[AWS Organizations における組織単位のベストプラクティス \| Amazon Web Services ブログ](https://aws.amazon.com/jp/blogs/news/best-practices-for-organizational-units-with-aws-organizations/)

> 推奨アカウント
> ログアーカイブ (Log Archive) : このアカウントは環境内のすべてのアカウントから収集されたセキュリティに関連する AWS アクセスログおよび監査ログを統合します。

上記の記述のように、クロスのアカウントのアクセスログおよび監査ログを一つのアカウント下に一元保存するのが推奨されているようです。

自分の個人アカウントで作成した AWS Organizations 環境下でもログアーカイブアカウントを作成し、そのアカウント下の S3 に全ての他のアカウントの CloudTrail のログを保存しています。

今回は、クロスアカウントの環境下で特定の一つのアカウントの S3 に収集対象のアカウントの Cloudtrail のログを集約する設定をやっていきます。
ついでにログの暗号に使用する CMK もアカウント間共有してみます。
因みにここで紹介する方法は、別に AWS Organizations を利用していなくても大丈夫です。

## 前提条件

- 保存する S3 バケット名は `aws-cloudtrail-logs` とします。
- CloudTrail ログが保存されるパスは `aws-cloudtrail-logs/AWSLogs/AWSアカウントID` とします。
  - アカウント ID が `111111111111` の場合は、`aws-cloudtrail-logs/AWSLogs/111111111111`
- 以下のようなアカウントをが作成されている想定です。
  |アカウント ID | アカウント名 | 備考 |
  | ------------- | ------------------- | -------------------------------- |
  | 999999999999 | LogArchive | CloudTrail ログを保管するアカウント |
  | 111111111111 | サービス A 開発環境 | CloudTrail ログを保管したいアカウントその 1 |
  | 222222222222 | サービス A 検証環境 | CloudTrail ログを保管したいアカウントその 2 |

## CloudTrail ログを保管するアカウント(LogArchive)側の設定

### CloudTrail 証跡の作成その 1

- CloudTrail → ダッシュボード → 証跡の作成
  - 証跡名は適当
  - 新しい S3 バケットを作成するを選択
    - [証跡ログバケット名] に適当なバケット名を入力
      - 本記事では `aws-cloudtrail-logs` とします。
  - AWS KMS カスタマー管理の CMK
    - 新規で作成を選択し、[AWS KMS エイリアス] を入力
      - 本記事では `aws-cloudtrail-logs-key` とします。
  - 残りの入力項目は適宜目的に応じたものを入力していき証跡を作成します。

### S3 バケットに「CloudTrail ログを保管したいアカウント」からのアクセスを許可する

S3 のコンソールに行くと CloudTrail 作成時に指定した S3 バケット (`aws-cloudtrail-logs`) が作成されているので、そのバケットの [アクセス許可] から [バケットポリシー] の編集を行います。

**バケットポリシー設定**
・ CloudTrail ログは収集対象のアカウント ID 毎のディレクトリに保存することとします。
・ `s3:PutObject` のアクションに対する `Resource` にログを保管するディレクトリを追加します。

```json fn=バケットポリシー設定
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AWSCloudTrailAclCheck20150319",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::aws-cloudtrail-logs"
    },
    {
      "Sid": "AWSCloudTrailWrite20150319",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": [
        "arn:aws:s3:::aws-cloudtrail-logs/AWSLogs/111111111111/*",
        "arn:aws:s3:::aws-cloudtrail-logs/AWSLogs/222222222222/*"
      ],
      "Condition": {
        "StringEquals": {
          "s3:x-amz-acl": "bucket-owner-full-control"
        }
      }
    }
  ]
}
```

### CloudTrail ログを暗号化するための CMK を「CloudTrail ログを保管したいアカウント」が利用できるようにする

- [Key Management Service (KMS)] → [カスタマー管理型のキー] で証跡の作成時に [AWS KMS エイリアス] に入力したエイリアス名 (`aws-cloudtrail-logs-key`)
  - キーポリシーの編集から、`kms:GenerateDataKey*` アクションの `Condition` に「CloudTrail ログを保管したいアカウント」の CloudTrailService の `arn` を追記します。

```json fn=キーポリシー(一部抜粋))
{
  "Sid": "Allow CloudTrail to encrypt logs",
  "Effect": "Allow",
  "Principal": {
    "Service": "cloudtrail.amazonaws.com"
  },
  "Action": "kms:GenerateDataKey*",
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "kms:EncryptionContext:aws:cloudtrail:arn": [
        "arn:aws:cloudtrail:*:111111111111:trail/*",
        "arn:aws:cloudtrail:*:222222222222:trail/*"
      ]
    }
  }
}
```

## CloudTrail ログを保管したいアカウント(サービス A 開発環境、サービス A 検証環境)側の設定

### CloudTrail 証跡の作成その ２

- CloudTrail → ダッシュボード → 証跡の作成
  - 証跡名は適当
  - 既存の S3 バケットを使用するを選択します。
    - [証跡ログバケット名] に CloudTrail ログを保管するアカウント (LogArchive) の CloudTrail で作成した S3 バケット名 (`aws-cloudtrail-logs`) を直接入力する。([参照] を押しても S3 バケット名は表示されません)
      - [プレフィックス - オプション] は未入力で大丈夫です。もし、プレフィックスを利用する場合は、S3 のバケットポリシーを編集して、CloudTrail にプレフィックスを含めたディレクトリにアクセスする許可を与えてください。
  - AWS KMS カスタマー管理の CMK
    - 既存を選択し、[AWS KMS エイリアス] にログを保管するアカウント (LogArchive) の CloudTrail で [AWS KMS エイリアス] に入力した CMK (`aws-cloudtrail-logs-key`) の `arn` を直接入力します。(:span[オートコンプリートで表示されたりしません]{style="color:red"})
  - 残りの入力項目は適宜目的に応じたものを入力していき証跡を作成します。

## 動作確認

- CloudTrail ログを保管するアカウント (LogArchive) アカウントで S3 バケットにアクセスし、アカウント毎のディレクトリに CloudTrail のログが出力されていれば OK です。

## まとめ

- 今回 AWS Organizations のクロスアカウント管理のベストプラクティスとして CloudTrail などのセキュリティーログを集約/保存するアカウントに保存するのをやってみましたが、CMK 含めいい勉強になりました。
- 本記事では開発・検証と行った本番系以外のアカウントの CloudTrail をそれ専用アカウントに集約した形ですが、本番系だと当然、サービス A 本番アカウントと本番系の CloudTrail を集約/保存するアカウントを作成する必要があるので、AWS Organizations のアカウント作成上限に到達してしまう点は注意が必要です。事前に AWS Organizations に登録可能なアカウントの上限緩和申請しておくことをお勧めします。

## 参考文献

<https://aws.amazon.com/jp/builders-flash/202009/multi-accounts-best-practice-2/>


AWS CloudTrail の記事一覧

Amazon Connect の緊急管理者ログインをリアルタイムに検知する

クロスアカウントの CloudTrail ログを特定のアカウントの S3 バケットに保存する