【Amazon Connect】Emergency Accessのあれこれ

## はじめに

Amazon Connectを利用する際に、運用上Emergency Accessを利用せざるを得ないケースもありますが、その際に仕様を理解すべく調査を行ったのでその備忘です。

## Emergency Accessとは
Amazon Connectに対する緊急用のログイン手段として[Emergency Access](https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/emergency-admin-login.html)が提供されています。
Emergency Accessを実施するにはAWSアカウントの認証情報が必要で、マネジメントコンソール等からアクセスすることになります。この方法でログインしたユーザーは、Amazon Connect上で全権限を持つことになるためあくまでも緊急用のアクセス手段という位置付けになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3998055/23f1b6bc-6da6-4852-b5b8-ac2a9c3df7cc.png)



## 仕組み
Emergency Access用のリンクは以下のようなものになっています。（一部塗りつぶし）
```
https://ap-northeast-1.signin.aws.amazon.com/oauth?client_id=arn%3Aaws%3Asignin%3A%3A%3Aconsole%2Flily-onboarding&code_challenge={================}&code_challenge_method=SHA-256&response_type=code&redirect_uri=https%3A%2F%2Fap-northeast-1.console.aws.amazon.com%2Fconnect%2Fv2%2Ffederate%3Fadmin%3Dtrue%26arn%3Darn%253Aaws%253Aconnect%253Aap-northeast-1%{この辺りにインスタンス情報}%26isauthcode%3Dtrue%26oauthStart%{==============}%26state%3DhashArgsFromTB_ap-northeast-1_{===============}
```
このリンクからEmergency Accessの流れとしては

1. **AWSのサインインエンドポイントへアクセス**
1. **IAMユーザーの認証を実施**
1. **フェデレーションユーザーとして対象のAmazon Connectへログイン**

となっていることがわかります。



## IAMロールでのアクセス制限
Emergency AccessはIAMロールに拒否ポリシーを付与することで制限することが可能です。（[参考](https://docs.aws.amazon.com/ja_jp/service-authorization/latest/reference/list_amazonconnect.html)）

制限するポリシーは`connect:AdminGetEmergencyAccessToken`です。([Amazon Connectの管理者ガイド](https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/security-iam-amazon-connect-permissions.html) では"connect:GetFederationTokens"と記載がありますが現在必要な権限は変更されています)

これは前章で記載の通り、IAMユーザーからフェデレーションを実施してAmazon Connectにログインが行われることに対してフェデレーションを制御するものになります。

例えば特定のユーザーのEmergency Accessを制限するIAMポリシーは以下のようになります。

```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyEmergencyAccess",
            "Effect": "Deny",
            "Action": "connect:AdminGetEmergencyAccessToken",
            "Resource": "*",
            "Condition": {
                "StringEqual": {
                    "aws:userid": "{ユーザーID}"
                }
            }
        }
    ]
}
```

## ユーザーの判別

Emergency Accessを実施した際に「どのIAMユーザーがEmergency Accessを実施して操作を行ったのか」が分かるのかを検証しました。


### Amazon Connectの画面上における表示

①IAMユーザー＝Connect1
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3998055/ac26aba7-bfbb-4f2f-956f-366c3c602c34.png)

②IAMユーザー＝Connect2
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3998055/73c3c586-32a7-4bcc-a9e0-e7d5df7a6036.png)

別のIAMユーザーとしてEmergency Accessを実施した場合でもAmazon Connectの画面上からは同じユーザー名が表示されていました。
ただ、ログイン状態が競合することはなく双方で同時に操作を実施することができました。


### CloudTrailにおける判別


①IAMユーザー＝Connect1
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3998055/f9d9aa68-e381-492d-b72d-27588fd12aca.png)

②IAMユーザー＝Connect2
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3998055/f19493b6-b852-4c7a-b401-a9f4a4e6a758.png)

Emergency Access実施後はIAMユーザー毎に一定のユーザー名で証跡が記録されていることが分かります。
ただし AdminGetEmergencyAccessTokenのイベントレコードとその後のAmazon Connect上での操作のイベントレコードを紐づけるような情報は確認できませんでした。

そこで、同一IAMユーザーが一度マネコンからログアウトした後に再度ログインしてEmergency Accessを試みた場合の証跡についても確認しました。

①-2 IAMユーザー＝Connect1 ＜再ログイン＞
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3998055/5d137a62-d787-435f-a51b-efd768a990e0.png)

結果として、1度目と同様のユーザー名（c8b487...）が記録されていることが分かりました。
つまり、Emergency Access実施時にCloudTrail上に記録されるユーザー名とIAMユーザーのマッピングさえ把握できていれば、**「誰がEmergency AccessユーザーとしてAmazon Connect上の操作を行ったか」は検証可能**であることが分かりました。



## まとめ

Emergency Accessは
- AWSアカウントへのログイン認証をもとに全権限をもつフェデレーションユーザーとしてログインを許可するものである
- IAMポリシーにより実施の可否は制限可能
- CloudTrail上で誰がEmergency Accessを実施して操作したのかを判別することが可能