LoginSignup
6
0

個人GitHubにAWSキーペアをアップロードしてしまったお話

Last updated at Posted at 2023-12-05

前書き

個人GitHubに(個人の)AWSのキーペアをアップロードしてしまい、流出してしまったというお話です。
一昔前は不正利用で大金を請求されてしまう事例をよく目にしましたが、最近はあまり聞きませんね。
AWSが不正利用され300万円の請求が届いてから免除までの一部始終
AWSで不正利用され80000ドルの請求が来た話
恥ずかしながらやらかしてしまったので、自戒を込めて発覚した経緯をとその後をまとめていきます。
なお、すぐに対応できたので不正利用はされず大金も請求されませんでした。

流出した経緯

個人のGitHubでAWS CDKの練習用にPrivateリポジトリを作成したのですが、
それをPublicにしてしまったことでキーが流出してしまいました。
具体的には下記の手順です。

手順
  1. CDKプラクティス用のPrivateリポジトリを作成
  2. AWS認証情報をmain.ymlに直書きしてPush
  3. 認証情報をGitHubのSecretsから取得するように変更してPush
  4. GitHubのリポジトリをPublicに変更 ←キー情報漏洩
なぜ上記手順でPublicに変更したのか

作成したCDKファイルを学習用としてメンバに公開しようと思い、Publicに変更しました。
ここで私が1つ勘違いをしていたのですが、
最初からPrivateだったリポジトリをPublicに変更する時、コミット履歴は公開されないと勝手に思い込んでいました。

そのため、手順3で認証情報をSecretsから取得するようにしたソースはPublicに変更しても問題ないと思っていましたが、コミット履歴にガッツリ認証情報が残っており、そこから流出しました。

発覚した経緯

Publicにした後すぐにコミット履歴も公開されていることに気づき10分以内にはPrivateに戻したので安心していましたが、
Publicに変更後30分ほどでAWSからメールが届きました。

ACTION REQUIRED: Your AWS Access Key is Exposed for AWS Account {AccountID}

メールには
流出したキーを持つuser名と、不正利用を防ぐためのPolicy※を付与したこと。
Policyを削除する前に対応すべきSTEPが記載されておりました。
AWSCompromisedKeyQuarantineV2
このPolicyは削除非推奨のようです。

IAM ユーザーの認証情報が侵害されたり、公開されたりした場合に、AWSチームによって適用される特定のアクションへのアクセスを拒否します。このポリシーを削除しないでください。

流出後にやること

AWSからのメールの通りに下記手順で対応しました。

  1. キーをローテートして削除する
  2. AWS CloudTrail ログで認可されていないアクティビティを確認する
  3. Budgetの請求対象に不審なリソースがないか確認する
  4. AWSのサポートに連絡を行う※

※私のAWSアカウントはサポートを作成できないプランですが、
サポートページを開くとこの件のサポートケースが作成されておりすぐに連絡できるようになっていました。
 対応内容に不安点がある場合は、サポートセンターに連絡しましょう。

ちなみに流出したUserのIAMキーを削除するとAWSから5分以内に「キーを削除してくれてありがとう!」というメールが届きました。

+αでやったこと

AWS全リージョンのリソースを削除するために「aws-nuke」を使い、 GitHubで認証情報をコミットできないように「git-secrets」を使いました。

aws-nuke

不正に作られたリソースを把握しようとTag&ResoureceMangerで全リージョンで検索をかけたのですが各リージョンに作成されたデフォルトVPCとそれに付随するRouteTableなどが多すぎて全体像の把握が難しかったです。
チームで利用しているアカウントでの利用は難しいと思いますが、
私は個人AWSアカウントで特に残しておきたいリソースがなかったので、「aws-nuke」で全リソースを削除しました。

AWSのリソースが一括削除できる『aws-nuke』の実行手順

実行後、Tag Editorで「All Region&ALl supported resouces type」でリソースを検索すると、
削除前は約200あったリソースが約50まで減りました。

実際に実行したファイルはこちらです。
削除したくないリソースはexcludesに追加して実行してください。

aws-nukeで指定可能なリソース一覧は下記コマンドで確認できます。

aws-nuke resource-types
※[AWSのリソースが一括削除できる『aws-nuke』の実行手順]の手順で準備した場合は下記コマンドになります。
(./aws-nuke-v2.21.2-linux-amd64)

nuke-config.yml
regions: 
- us-east-2
- us-east-1
- us-west-1
- us-west-2
- af-south-1R
- ap-east-1
- ap-south-2
- ap-southeast-3
- ap-southeast-4
- ap-south-1
- ap-northeast-3
- ap-northeast-2
- ap-southeast-1
- ap-southeast-2
- ap-northeast-1
- ca-central-1
- eu-central-1
- eu-west-1
- eu-west-2
- eu-south-1
- eu-west-3
- eu-south-2
- eu-north-1
- eu-central-2
- il-central-1
- me-south-1
- me-central-1
- sa-east-1
- us-gov-east-1
- us-gov-west-1
- global

account-blocklist:
- 000000000 
resource-types:
  excludes:
  - IAMRole
  - IAMRolePolicyAttachment
  - IAMSAMLProvider
  - IAMRolePolicy
accounts:
  <自身のAWSアカウントID>: {} 

CloudShellにコピーするときにインデントが崩れる場合があります。

インデントが正しくないとエラーが発生するので、うまくいかないときはインデントを見直してみてください。

git-secrets

GitHubで設定することで、ソースコードにAWS認証情報が含まれている場合にCommitを防いでくれます。
https://github.com/awslabs/git-secrets

最後に

思い込みに気をつけよう

GitHubは使い始めてから長いですが、 PrivateなリポジトリをPublicにすることは初めてやりました。
今回の件で長年使っているツールでも思い込みで危険な操作をすることはあるということを実感しました。
普段と違う操作を行うときは思い込みを排除して公式HPなどで挙動を確かめてからやりましょう!

セキュリティ関連のベストプラクティスを復習しよう

それと、AWS公式HPやQiitaでこの辺りのベストプラクティスは公開されているので
目を通しておくと良いと思います!

AWS アクセスキーを管理するためのベストプラクティス
AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ

6
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
6
0