アクセスキーをどうしても使いたい方へ

こんにちは！
皆さんはAWSの利用時にアクセスキーを利用したくなったことはありますか？
私はありません！

アクセスキーは容易に発行できる認証情報ではありますが、ひとたび漏洩するとAWSリソースへの不正アクセスを引き起こす危険性があります。

本記事ではアクセスキーの概要やAWSが推奨する認証方式を紹介しつつ、それでもアクセスキーを使わなければならない場合に取っておくべき対策について説明します。

# アクセスキーとは何か
アクセスキーとはIAMユーザーまたはAWSアカウントのルートユーザーの長期的な認証情報であり、アクセスキーIDとシークレットアクセスキーで構成されています。アクセスキーを利用することで、AWS CLIやAWS SDKからサービスへのリクエストを実行することができます。

また安全にローテーションができるよう、ユーザーごとに最大2つまで発行することができます。つまり新しいアクセスキーを発行した後で、古いアクセスキーを削除するといった対応が可能ということになります。

:::note info
アクセスキーとは別に**IDとパスワード**の組み合わせからなる認証情報も存在します。こちらはAWSマネジメントコンソールのログインに使用されます。
:::

# アクセスキーの作成方法
IAMユーザーの設定画面にある「セキュリティ認証情報」を開くと、中段にアクセスキーの設定が表示されます。「アクセスキーを作成」を押下することで作成画面に遷移します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3665293/f5c00b76-139f-c009-95f1-cca5abdc1b46.png)

アクセスキーの用途を問われるため、選択すると推奨とする代替案が提示されます。代替案を採用できない場合は、「確認」にチェックを入れ、「次へ」を押下します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3665293/6a8fe28d-a22b-812e-ad9f-9bd9ffebab0b.png)

ちなみに各ユースケースで推奨される代替案は以下の通りです。
| ユースケース | 代替案 |
|:-----------|:------------|
|コマンドラインインターフェイス (CLI)|AWS CloudShellの使用、またはAWS CLI v2にてIAM Identity Centerによる認証を利用|
|ローカルコード|AWS Toolkitをサポートする統合開発環境(IDE)上で、IAM Identity Centerによる認証を利用|
|AWSコンピューティングサービスで実行されるアプリケーション|EC2やLambda等にIAMロールを付与して一時的な認証情報を利用|
|サードパーティーサービス|IAMロールによる一時的な認証情報を利用|
|AWS の外部で実行されるアプリケーション|IAM Roles Anywhereを使用して、一時的なセキュリティ認証情報を生成|

必要に応じてタグを設定し、画面を進むとアクセスキーを取得することができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3665293/2e099281-2a30-537e-66f9-19aa445a473d.png)

作成したアクセスキーの設定画面より「アクション」を押下すると、無効化や削除を実行することができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3665293/0331141c-bccd-58af-1450-ba5f1e70b362.png)

# なぜアクセスキーの利用が推奨されないのか
アクセスキーは長期的な認証情報であり、削除や無効化しない限り半永久的に利用することができます。そのため、漏洩したことに気づかないと、いつまでも不正アクセスを許してしまうこととなります。

ではアクセスキーの情報はどのようにして漏洩するのでしょうか。よくあるのは、アクセスキーの情報をそのままハードコーディングし、GitHubの公開リポジトリに保存することで、第3者が認証情報を不正に入手したというケースです。

またメールやチャットを通じ他者に共有したところ、共有先での管理が不十分であったため流出するといったことも考えられます。複数人での使い回しは、管理の煩雑化を招き、漏洩のリスクが高くなることに注意しなければなりません。

漏洩したアクセスキーの不正利用を許すと、ストレージやDBに保存された機密情報の窃取や、高額なサービスの立ち上げによる過剰請求の発生といった問題に繋がる危険性があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3665293/0ad786ae-fbb0-9eed-dbd4-ac81459a8928.png)

# アクセスキーの代替手段
ではどうすればいいのでしょうか？

一番の対策として、アクセスキーのような長期的な認証情報ではなく、一時的な認証情報を利用することが挙げられます。仮に漏洩した場合でも一定時間が経過すると認証情報が失効するため、被害を最小限に抑えることが期待できます。
一時的な認証情報として、IAMロールの利用が考えられます。認証の有効期限はデフォルトで1時間、最大12時間となっております。

またマルチアカウント構成において代表的な手法としては、以下の二つが考えられます。

1. AWS STSの利用
AssumeRole APIを呼び出すことで、指定されたIAMロールを引き受け、一時的なセキュリティ認証情報を取得します。

2. IAM Identity Centerの利用
シングルサインオンを通じてAWSアカウントへアクセスします。AWS Identity Centerを利用することで、ユーザーは一元管理されたIDプロバイダーを通じてAWSリソースにアクセスできます。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3665293/b9c86216-c148-0abb-654e-dfe9d9c77914.png)

他の認証方式については以下の記事をご参照ください。

https://blog.serverworks.co.jp/summary-of-getting-security-credentials-from-sts

# アクセスキー利用時の対策
しかしそれでもアクセスキーを利用せざるを得ないケースが存在するかもしれません。そのような場合は、「漏洩を防止する」「仮に漏洩した場合の被害を抑える」といった対応が求められます。

## アクセスキーの漏洩を防止する方法
### 二要素認証（MFA）を利用する
設定したIAMユーザに対してはMFAを必ず設定してください。

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa.html

### アクセス元を制限する
アクセスキーの利用者が分かっている場合は、IAMポリシーを利用し特定のIPアドレスや条件に基づいてアクセスを制限しましょう。
例えば203.0.113.0/24以外から、S3に対するオブジェクトの取得を禁止するIAMポリシーは以下の通りとなります。
```json
{  
    "Version": "2012-10-17",  
    "Statement": [  
        {  
            "Effect": "Deny",  
            "Action": "s3:GetObject",  
            "Resource": "arn:aws:s3:::example-bucket/*",  
            "Condition": {  
                "NotIpAddress": {  
                    "aws:SourceIp": "203.0.113.0/24"  
                }  
            }  
        }  
    ]  
}  

``` 
他にもCondition句に、`Bool`を指定することで多要素認証（MFA）が使われている場合のみアクセスを許可したり、`DateGreaterThanEquals`や`DateLessThanEquals`を指定することで特定の時間帯にのみアクセスを許可すしたりといった制限が可能です。

https://dev.classmethod.jp/articles/keep-this-on-secure-iam-policies/


### 不要になったアクセスキーは削除する
AWS IAM Access Analyzerを利用すると、一定期間未使用のアクセスキーを検出することができます。不要なアクセスキーは適宜削除しましょう。

https://dev.classmethod.jp/articles/introduction-2024-aws-iam-access-analyzer/

### 定期的にローテーションする
利用中のアクセスキーであっても、定期的にローテーションを行う仕組みを実装しましょう。

https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-rotate-iam-user-access-keys-at-scale-with-aws-organizations-and-aws-secrets-manager.html

### アクセスキーの情報をハードコーディングしない
アクセスキーの文字列をそのまま記述するのではなく、環境変数やAWS Secrets Managerなどの秘密管理サービスを利用してください。

またAmazon Q Developerを利用し、セキュリティチェックを行うことが可能です。
以下のように意図的にアクセスキーを設定した状態でセキュリティスキャンを依頼してみます。（今回はサンプルのデータを入力しています）
```python
import boto3

client = boto3.client(
    aws_access_key_id="AKIAIOSFODNN7EXAMPLE",
    aws_secret_access_key="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
)
```
結果、認証情報がハードコードされていると指摘を受けました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3665293/82d66592-ab71-798d-6e41-2894a7bec5eb.png)
対策についてもアドバイスしてくれました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3665293/30ff6ec3-87e4-6fc0-7ebd-74f3e2156006.png)

さらに他の手段として、git-secretsを利用することで、アクセスキーの情報が含まれたコードのコミットを防ぐことが可能です。

https://dev.classmethod.jp/articles/prevent-commit-using-git-secrets-and-husky/

### アクセスキーの利用ルールに違反していないかチェックする
AWS Security Hubを利用することで、AWSのベストプラクティスから逸脱した設定や構成がないかチェックすることができます。アクセスキーに関する主なチェック項目は以下の通りです。
+ [[IAM.3] IAM ユーザーのアクセスキーは 90 日以内にローテーションする必要があります](https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/iam-controls.html#iam-3)
+ [[IAM.8] 未使用の IAM ユーザー認証情報は削除する必要があります](https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/iam-controls.html#iam-8)
+ [[IAM.22] 45 日間未使用の IAM ユーザー認証情報は削除する必要があります](https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/iam-controls.html#iam-22)

AWS Security Hub は、 AWS Configルールを使用してセキュリティチェックを実行します。AWS Configにもアクセスキーに関するルールは存在します。アクセスキーが指定された期間内（デフォルトは90日間）にローテーションされていない場合は非準拠として記録されます。
https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/access-keys-rotated.html
また非準拠と判定された場合、自動的にアクセスキーを無効化することが可能です。

https://dev.classmethod.jp/articles/aws-config-access-keys-rotated/

## アクセスキー漏洩時の被害を抑える方法
### 最小限の権限を設定する
必要な人に対し必要な権限のみ設定してください。AdministratorAccessやPowerUserAccessといった広範な権限は利用を避けるべきです。

### アプリケーションごとにアクセスキーを使い分ける
複数のアプリケーションに対し共通のアクセスキーを利用する場合、不正アクセスが発生すると被害が拡大する恐れがあります。アプリケーションごとにアクセスキーを使い分けることでアクセス許可を分離させることが可能です。

なお管理するアクセスキーが増加すると、不正アクセスの被害範囲は抑えられる一方で、漏洩のリスクは高まります。本当にアクセスキーを利用しなければならないのか、アプリケーションごとに判断し、必要最小限の利用に収めてください。

### アクセスキーの利用状況を記録する
AWS CloudTrailでは、アクセスキーがいつどのリソースに対して利用されたのかが記録されます。仮に不正アクセスを検知した場合、アクセスキーのIDでフィルターをかけることで。被害を受けた範囲を特定することが可能です。ただし、無効化されたアクセスキーはCloudTrailのイベント履歴上には表示されないため、S3などにログを保存することを推奨します。

https://dev.classmethod.jp/articles/check-the-log-of-the-disabled-access-key/

なおアクセスキーを複数名で共有するといった運用の場合、ログを見ても誰が操作したのか判別が難しくなるため、注意が必要です。

### 脅威検知を有効化する
不正アクセスが発生した場合、いち早く気付けるようAWS GuardDutyを有効化しましょう。
普段とは異なるAPI操作や、悪意のある既知のIPアドレスからの通信などを検知することが可能です。

https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_finding-types-iam.html

## おわりに
いかがだったでしょうか。

アクセスキーの漏洩は人為的に発生するものです。厳格なセキュリティポリシーを定める、セキュリティ研修を実施するといった対応だけでは完全に防ぐことはできません。

ルールから逸脱したような行為は予防し、不正利用が発生した際は速やかに対処できるよう、AWS（またはサードパーティ）のツールを上手に活用することが重要です。


## 参考
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_access-keys.html

https://dev.classmethod.jp/articles/unauthorized-use-of-aws-access-keys-due-to-leakage/