AWSアカウント運用改善の取り組み

f:id:kiyotaka_ginoza:20210405181545p:plain
こんにちは!
アンドパッド SREの宜野座です。

ANDPADではAWSを主要なクラウドとして利用させていただいているのですが、続々と社内でAWSを利用する方が増えていることでAWSアカウントの運用も少しずつ煩雑になってきています。

IAMやアカウントの管理に関する議論が2019年末頃からSREでは始まりましたが、具体的に動き出せたのは2020年夏ごろでした。

最近では週1くらいのペースでMTGを行いながら今後のアカウント改善に向けた取り組みを行っています。


今回は

  • IAMの運用改善への取り組みの中で行ったこと
  • AWS Organizationsを導入していく際に注意したポイント
  • 将来的な取り組み

についてご紹介させていただければと思います。

IAM運用改善の取り組みの中で行ったこと

すべてのIAMアカウントを洗い出す

地味ですが、まずは所有しているアカウントの洗い出しを行いました。

AWSではIAMの認証情報レポートから、IAMの利用状況やアクセスキー の有無、MFAの有効化、パスワードの変更履歴など、様々な現状のIAMに関する情報を知ることができます。

f:id:kiyotaka_ginoza:20210402131849p:plain
認証情報レポート


こちらも合わせて活用しつつ、長期間利用されていないクレデンシャルの洗い出しをしました。

その後、CloudTrailコンソール、IAMアクセスアドバイザーなどを利用して、実際のAPIの活動ログなどが吐き出されていないかを確認しながら不要なユーザーを削除していきました。

特に下記2点には注意していました。

  • CloudTrailコンソールに記録されないアクティビティが存在しないか確認する
  • アクセスキーが発行されている場合はいきなり削除をせず、一旦無効化をし、一定の期間経過を観察後(AccessDeniedなどのエラーが大量に発生していないか、など)削除する

IAMグループ運用について考える

次に各アカウントを極力グループ管理、かつフォーマットされた権限が用意できるとアカウント発行の手間を軽減できるのでは?ということから、IAMの現状のグループを洗い出しながら(グループにはどの権限があり、誰が参加しているのか、権限の修正が必要なのかなど)どのように運用するのが望ましいかを検討し始めました。

しかし、検討していく中でいくつか課題が出てきました。

  • 複数チームに所属している人の権限をどうするか (IAMグループには10グループまでしか所属できないという制限がある。)
  • チーム全員が同様の権限でいいのか
  • 関わる範囲が明確に分離できていない以上、グループ管理は今の組織にそのままシンプルには当てはめられない

etc...

いくつか課題が出てきたことで、IAMのグループ運用ポリシーはこうである。というものが、現状のままではうまく定められないことが良くも悪くもわかりました。

そのため、課題を少しづつ片付けながらグループ運用を少しずつ定めていく方針になりした。

不要なIAM権限の整理、置き換え

マシンユーザーとして過去に発行されたユーザーには、広めの権限が付与されたままのアカウントが存在していたりすることがあると思います。

しかし、実際に使われているものは1つ、2つのアクションのみであったりします。

具体的に実行に使用しているアクションを特定するためにはCloudTrailが役立ちます。

今回調査したもののいくつかはS3のオブジェクトレベルでのログを調べる必要があったため、まずはCloudTrailのログへクエリをかけられる状態にすることから始めました。

S3のオブジェクトレベルのイベントやLambda,DynamoDBのデータイベントなどが実行された記録はデフォルトでは残らず、追加料金が発生しますがCloudTrailの設定で有効化にすることで取得することができます。

docs.aws.amazon.com

docs.aws.amazon.com

上記のデータイベントは保存した場合もCloudTrailコンソールから検索することはできないため、S3へクエリをかけて検索する必要があります。

そこでAthenaを利用して、CloudTrailのログにクエリをかけて利用しているAction、Resourceを特定して権限を適切に絞ることができました。

dev.classmethod.jp


その他にも、過去の経緯でカスタムメトリクスを送るように設置されていたクレデンシャルなどをDatadogなどの監視SaaSに置き換えることで、静的クレデンシャルの廃止につなげる取り組みも行われています。

www.datadoghq.com

ロールへの置き換え

AWSでは基本的に EC2やECS, EKSなどのサービスから他のサービスを利用する際にアクセスキーなどの静的クレデンシャルの利用を推奨しておりません。

IAMロールで一時的な認証情報を利用してやりとりすることが、推奨されています。

すべてのケースに適応するのは難しい場合もあるかとは思いますが、利用できる場合は基本的にロールで認証情報をやりとりするようにすることで鍵の交換する手間を省くことができます。

aws.amazon.com

AWS Organizationsを導入していく際に注意したポイント

AWS Organizations 導入のメリット、デメリット

多くの企業で事業の成長、開発部の人数の増加、などさまざまな理由がありAWSのアカウントの数が増えていく傾向にあると思います。

その時に複数のアカウントを管理するために、非常に便利なのがAWS Organizationsです。

AWS Organizationsを導入することで以下のようなメリットがあると思います。

  • 請求アカウントを統合できる
  • SCPによるアカウント全体で利用できる範囲の統制
  • リザーブドインスタンスを共有できる
  • Control Tower, Firewall Manager, AWS BackupなどOrganizationsを有効化することで使用できるものや機能が拡張されるものがある
  • アカウント発行が容易になる
  • AWS SSOなど

etc...

目立ったデメリットはないですが、強いて挙げるとするなら

  • どのような役割でどのアカウントを使うかなど別の視点で考える必要がある
  • 全体にガバナンスを適切に効かせるためには、いくつかの新しいサービスを学び運用していく必要がある
  • しっかり設計をしておかないと、不要なアカウントが増え統制しづらくなっていく可能性がある
  • AWS SSO, 踏み台アカウント + スイッチロールなど仕組みを整えないとログインする手間が増える

が挙げられるかと思いました。

AWS Organizations導入の際に考えたこと

OU(Organizations Unit) という単位で組織を管理することになるのですが、その設計が非常に重要です。

この設計をしっかり考えておかないと後々理解しにくく、拡張性に乏しい運用となってしまいます。

世の中的にはいろいろな企業でも導入の事例などは出てきておりますが、AWSのベストプラクティスが参考になりました。

dev.classmethod.jp

aws.amazon.com

この中で様々なOUが定義されています。
(各OUの具体的な役割に関しては上記のベストプラクティスをご参考ください)

  • Infrastructure OU
  • Security OU
  • Sandbox OU
  • Workload OU
  • PolicyStaging OU
  • Suspended OU
  • IndividualBusinessUsers OU
  • Exceptions OU
  • Deployment OU


設計のポイントは

  1. 将来の拡張性を意識すること
  2. 組織の状態に適したOUを作成すること
  3. SCPの適応が必要に応じてできること

になるかと思います。

将来的な取り組み

  • AWS SSOの導入

AWS SSOなどを導入して、可能な限りシンプルにユーザーの一元管理を行っていきたいと思っています。
具体的な方針等はこれからさらに検討していくことになりますが、こちらの記事が非常に参考になりました。

blog.takuros.net

  • SCPによるアカウントに必要な機能の制御

AWS Organizations には SCP(サービスコントロールポリシー )という機能があり、アカウントで使用できるサービスやリージョンの制限などを行うことができます。
リージョンやサービスを必要な範囲内で利用できるようにすることで、アカウントを侵害された際の被害を少なくする効果もあると思われます。

aws.amazon.com

  • AWS Organizations導入によって使えるようになるサービスの活用

Control Tower, Firewall Manager, AWS Backupなど、AWSにはOrganizationsを導入することでアカウントの管理を便利に行うことのできるサービスが複数存在します。

こういったサービスを活用することでより便利で、より安全にアカウントを管理していくことができると考えます。

使えるようになる機能や、サービスの機能が拡張されるリスト
docs.aws.amazon.com

まとめ

IAMの管理は

  • 定期的に不要なクレデンシャルが存在しないか、不審な利用がされていないかを確認すること
  • 権限を適切に絞ること

アカウントの管理は

  • しっかりとOUの設計をすること

が大切だと感じました。

アカウント運用改善、権限の適切な管理をするのは、開発に利用する方が手間なくAWSを利用でき、セキュアな状態を維持するために非常に重要な取り組みと思います。

IAMの管理が大変、Organizations入れたいけどそこまで必要性をまだ感じてないという方にも何か参考になるものがあれば幸いです。

お読みいただきありがとうございました。

おわりに

まだまだアンドパッドにはさまざまな課題があります。

アンドパッドでは共に課題を解決していける新しい仲間を募集しています。

SREも、その他のポジションも、お気軽にエントリーお待ちしております。

engineer.andpad.co.jp

hrmos.co