Zenn
☁️

AWS を安全に利用するために知っておくべき アクセスキーの扱い方

2022/05/03に公開
AWS
tech

こんにちわ alivelimb です。
AWS を外部から利用するためにアクセスキーを発行した場合、安全に利用しないと不正利用される原因にもなりえます。本記事では AWS アクセスキーの扱いについて紹介します。

私は情報処理安全確保支援士、Security Specialty を含む AWS11 資格を取得していますが、セキュリティエンジニアではありません。ですが私のようにセキュリティエンジニアではない方でも、AWS を安全に使う上で知っておいてほしい内容をまとめました。なお、AWS 資格については記事にしているので適宜参照して下さい(私が AWS を 11 冠するまでにやったこと)。

アクセスキーをそもそも発行しない

アクセスキーを最も安全に扱う方法は、そもそも発行しないことです。アクセスキーの代わりに IAM ロールを利用する方法があります。

IAM ロールを付与した EC2 で開発サーバを用意する

AWS CLI で S3 のバケット一覧を表示する例で考えてみます。

IAM ユーザで行う場合は

  1. AWS マネコン: IAM ユーザを作成する
  2. AWS マネコン: IAM ポリシー(AmazonS3ReadOnlyAccessなど)を IAM ユーザに付与する
  3. AWS マネコン: IAM ユーザのでアクセスキーを発行する
  4. ローカル: aws configureでアクセスキーを設定する
  5. ローカル: aws s3 lsを実行する

の手順になります
※マネコン: マネージドコンソール

一方でアクセスキーを発行せず、IAM ロールと EC2 を利用する場合は

  1. AWS マネコン: IAM ロールを作成する
  2. AWS マネコン: IAM ポリシー(AmazonS3ReadOnlyAccessなど)を IAM ロールに付与する
  3. AWS マネコン: EC2 を作成する(IAM ロールを付与する)
  4. ローカル: EC2 に SSH などでアクセスする
  5. EC2: aws s3 lsを実行する

の手順になります。
※1: 実際は VPC や SG の作成、踏み台 EC2 の作成などが入るのでもう少し手順は増えるかと思います。
※2: 外部サービスからのアクセスの場合は EC2 ではなく Cognito などが考えられます。

アクセスキーを発行しないものの、SSH キーペアは発行することになるので秘密情報がアクセスキーから SSH キーペアに置き換わっただけという見方もできます。SSH の必要性や EC2 の費用も必要になります。

一方でセキュリティを担保しつつ、管理コストを下げる点では役に立ちます。新人などの AWS にあまり詳しくない開発者が誤った操作をしてしまった場合に備えて、ガードレールを用意しておくことができます。アクセスキーの発行自体を禁止したり、発行が検知されたらアラートを出す仕組みづくりも可能です。

もし IAM ユーザのアクセスキーを発行して EC2 にアクセスキーを登録して開発しているという場合は、アクセスキーを削除して IAM ロールを利用しましょう。また開発インスタンスはプライベートサブネットに置く、踏み台インスタンスには IP 制限をかけるなどのセキュリティ対策を実施しましょう。

アクセスキーを発行する場合

個人開発などの AWS 費用はできる限り抑えたく管理コストは重要じゃない場合、開発用 EC2 サーバを立てるのは適さないでしょう。この場合はアクセスキーを発行し、安全に管理していく必要があります。

ルートユーザの アクセスキーは絶対に発行しない

アクセスキーを発行する場合は必ず IAM ユーザのアクセスキーを発行し、ルートユーザのアクセスキーは発行しないようにします。また、AWS アカウント作成および削除の時以外は原則ルートユーザを使わないようにするべきです。これは公式ドキュメントでも推奨されています。

最小権限

アクセスキーを発行する IAM ユーザにはいくつか IAM ポリシー(権限)を付与すると思いますが、つける権限は必要最小限にするべきです。仮にAdministratorAccessを付与した IAM ユーザのアクセスキーが流出した場合、EC2 を大量に立てられて高額請求が来ることもあります。アクセスキーの発行する/しないに関わらず最小権限にしておくことは重要ですし、もちろん公式ドキュメントでもベストプラクティスとして紹介されています。

「セキュリティ的には悪いことと理解はしつつも、検証用にとりあえずAdministratorAccessを付ける...」なんてこともあるかもしれませんが、せめてアクセスキーを発行する IAM ユーザだけでも最小権限を意識して頂ければと思います。

AssumeRole を利用する

AWS には AssumeRole というアクションがあります。このアクションにより IAM ロールの権限を引き受ける(assume)ことができます。AssumeRole を使って先ほどの S3 の例を考えてみると

  1. AWS マネコン: IAM ロールを作成する
  2. AWS マネコン: IAM ポリシー(AmazonS3ReadOnlyAccessなど)を IAM ロールに付与する
  3. AWS マネコン: IAM ユーザを作成する
  4. AWS マネコン: sts:AssumeRoleを実行する権限を持つ IAM ポリシーを作成し IAM ユーザに付与する
  5. AWS マネコン: IAM ユーザのアクセスキーを発行する
  6. ローカル: aws configureでアクセスキーを設定する
  7. ローカル: aws sts assume-roleで IAM ロールの権限を引き受ける
  8. ローカル: aws s3 lsを実行する

の手順になります。前章の IAM ユーザと IAM ロールの手順を混ぜたみたいになっていますね。図にしてみると以下のようになります。

では AssumeRole を使うと何が嬉しいのでしょうか。AssumeRole により発行される認証情報は一時的なもの、つまり使用期限がある(デフォルト 1 時間)ため、長期的に有効な認証情報に比べて流出リスクが抑えることができます。またアクセスキーに紐づく IAM ユーザの権限を最小限に出来るのも良いですね。

AssumeRole についてはクラスメソッドさんが非常にわかりやすい記事を書いて下さっているので、適宜参照してください。私自身何度も読み返した記事です。

IP 制限、MFA 認証などの制限をかける

AssumeRole を利用してもアクセスキーが流出してしまった場合、今のままでは AssumeRole されて被害は変わりません。そこで IP 制限や MFA(多要素認証)の有効化をすることで被害を防ぐことができます。

まずは IP 制限です。固定 IP を持つプロキシがあるのであれば、アクセスキーを発行する IAM ユーザにアクセス元 IP 制限をかけることをおすすめします。SSH アクセスする開発用 EC2 があるならセキュリティグループにも IP 制限はかけておくべきでしょう。

IP 制限をかけた場合 CloudFormation などの AWS サービスが、ユーザに変わって AWS 環境を操作するサービスで IP 制限によるエラーが発生する場合があります。この場合「IP 制限は継続するが、AWS サービスのアクセスは許可する」設定が必要になります。詳しくはこちらもクラスメソッドさんの記事を適宜参照して下さい。

次に MFA ですが AssumeRole する際に、Google Authenticator などの MFA デバイスで取得したトークンコードが必要になります。万が一アクセスキーが流出した場合でもトークンコードが同時に盗まれない限り被害を防ぐことができます。

アクセスキーを発行する/しないに関わらず MFA を有効化しておくことは公式ドキュメントでも推奨されています。ルートユーザ、IAM ユーザには多要素認証を有効化しておきましょう。MFA 認証を強制することも可能です(参考)

流出被害を最小限に抑える

アクセスキーの管理には注意してきたにも関わらず、万が一アクセスキー流出してまった、もしくは何らかの方法で不正利用されてしまった場合に備えておくことは重要です。

請求アラートを設定する

AWS では予想請求額をモニタリングすることが可能です。事前にしきい値を決めておくと、予想請求額を超えた時にアラートを出すことができます。これはセキュリティというよりコスト管理のために設定しておいた方が良いでしょう。

CloudTrail で API 使用状況を追跡する

CloudTrail はユーザーアクティビティと API 使用状況の追跡するサービスです。誰が、いつ、どんな API を叩いたなどの情報を記録してくれます。CloudTrail のログでパスワードの変更後、EC2 などのリソース作成をしまくっているユーザがいれば怪しくなります。CloudTrail と CloudWatch アラームを組み合わせた検知フローを用意しておくことも可能です。

セキュリティサービスを活用する

AWS にはGuardDuty, Security Hub, Trusted Advisorなどセキュリティに関するサービスが多く存在します。ここでは紹介できていないサービスや各サービスの詳細は本記事では触れないため、公式ドキュメントやAWS サービス別資料を参照してください

まとめ

本記事では アクセスキーの扱い方に絞って AWS のセキュリティについて紹介しました。この記事で AWS のセキュリティについてもっと知りたいと思った方は、下記の AWS 公式ドキュメントのベストプラクティスなどを参照してください。また、開発者として最低限セキュリティの知識をつけたいと思った方は AWS 認定資格の受験も検討してみてください。

Discussion