2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめてのアドベントカレンダーAdvent Calendar 2024

Day 14

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

Last updated at Posted at 2024-12-14

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

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

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

アクセスキーとは何か

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

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

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

アクセスキーの作成方法

IAMユーザーの設定画面にある「セキュリティ認証情報」を開くと、中段にアクセスキーの設定が表示されます。「アクセスキーを作成」を押下することで作成画面に遷移します。
image.png

アクセスキーの用途を問われるため、選択すると推奨とする代替案が提示されます。代替案を採用できない場合は、「確認」にチェックを入れ、「次へ」を押下します。
image.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

作成したアクセスキーの設定画面より「アクション」を押下すると、無効化や削除を実行することができます。
image.png

なぜアクセスキーの利用が推奨されないのか

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

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

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

漏洩したアクセスキーの不正利用を許すと、ストレージやDBに保存された機密情報の窃取や、高額なサービスの立ち上げによる過剰請求の発生といった問題に繋がる危険性があります。
image.png

アクセスキーの代替手段

ではどうすればいいのでしょうか?

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

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

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

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

image.png

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

アクセスキー利用時の対策

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

アクセスキーの漏洩を防止する方法

二要素認証(MFA)を利用する

設定したIAMユーザに対してはMFAを必ず設定してください。

アクセス元を制限する

アクセスキーの利用者が分かっている場合は、IAMポリシーを利用し特定のIPアドレスや条件に基づいてアクセスを制限しましょう。
例えば203.0.113.0/24以外から、S3に対するオブジェクトの取得を禁止するIAMポリシーは以下の通りとなります。

{  
    "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)が使われている場合のみアクセスを許可したり、DateGreaterThanEqualsDateLessThanEqualsを指定することで特定の時間帯にのみアクセスを許可すしたりといった制限が可能です。

不要になったアクセスキーは削除する

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

定期的にローテーションする

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

アクセスキーの情報をハードコーディングしない

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

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

import boto3

client = boto3.client(
    aws_access_key_id="AKIAIOSFODNN7EXAMPLE",
    aws_secret_access_key="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
)

結果、認証情報がハードコードされていると指摘を受けました。
image.png
対策についてもアドバイスしてくれました。
image.png

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

アクセスキーの利用ルールに違反していないかチェックする

AWS Security Hubを利用することで、AWSのベストプラクティスから逸脱した設定や構成がないかチェックすることができます。アクセスキーに関する主なチェック項目は以下の通りです。

アクセスキー漏洩時の被害を抑える方法

最小限の権限を設定する

必要な人に対し必要な権限のみ設定してください。AdministratorAccessやPowerUserAccessといった広範な権限は利用を避けるべきです。

アプリケーションごとにアクセスキーを使い分ける

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

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

アクセスキーの利用状況を記録する

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

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

脅威検知を有効化する

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

おわりに

いかがだったでしょうか。

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

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

参考

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?