AWSセキュリティベストプラクティスを実践するに当たって適度に抜粋しながら解説・補足した内容を共有します

392件のシェア(そこそこ話題の記事)

こんにちは、臼田です。

皆さん、セキュリティ意識してますか?(挨拶

今回はお客様宛にAWSのセキュリティベストプラクティスについて補足・解説したものを汎用化して共有します。

公式のドキュメントだと少し硬くて読みづらいみたいなイメージもあるかと思いますので、こちらの記事を参考に感覚を掴んでいただければと思います。なお、いろいろ簡潔にしたりするためにすべてのことについて説明していませんのでご了承ください。

熟読いただきたい資料

AWSのセキュリティベストプラクティスの資料は本当は熟読していただきたいです。しかしながら、最初はとっつき辛いと思うのでこの先の内容を見ていただいて、余力があればこちらのセキュリティベストプラクティスを見ていってください。

https://d1.awsstatic.com/whitepapers/ja_JP/Security/AWS_Security_Best_Practices.pdf

以下箇条書きですが、やったほうがいいことと理由とか補足を入れています。

VPCの構成とアクセス制御

  • 1つのシステムは基本は1つのVPCにする
  • セキュリティグループがとりあえず0.0.0.0/0となっている事は避け、必要最低限に絞る
    • 基本はフロントとなるALBのみが0.0.0.0/0を受けるべきで、それ以外に0.0.0.0/0が付くことは避ける。特に開発環境(よく被害にあいます)。
    • セキュリティグループを作成する際には「MyIP」機能を利用して現在の送信元からのみ許可するなどの設定を行う。
  • セキュリティグループは基本セキュリティグループからのアクセスのみ許可する
    • インターネットを経由しないVPC内でのアクセス制御はIPではなくセキュリティグループIDを指定する。
    • これを常に意識することにより不特定な0.0.0.0/0が設定されることは格段に減る。
  • Webサーバ、APサーバ、DBは全てプライベートサブネットに設置し、メンテナンスが必要な場合には踏み台サーバを経由する
    • 内部からはNAT Gatewayを経由してインターネットアクセスする
    • DBは基本的に直接アクセスしない
  • RDSはパブリックアクセスを許可しない
    • DBがパブリックからアクセスされることは許可しない
  • 開発環境と本番でサブネットの構成を変えない
    • アクセス制限の内容も大きく変わるため開発環境であってもプライベートサブネットを活用する(開発環境が被害にあいやすい部分を補う意味もある)
  • VPC内から各種AWSリソースにアクセスする場合にはVPCエンドポイントを利用する

IAM管理とアクセス制限

  • IAMベストプラクティスに基本準拠する
  • すべてのコンソールログイン可能なIAMユーザーに対して MFA を有効化する
  • Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する
    • EC2から実行するAPIコールにはIAM Userのアクセスキーを利用しては「いけない」。必ずIAM Roleを利用する。
    • LambdaやCode系等各種サービスが利用するRoleについても同様
  • アクセスキーを共有しない
  • 複数アカウントにまたがるIAMを管理する場合にはIAM RoleによるSwitch User(Assume Role)を利用する
  • CodeCommitのHTTPSクレデンシャルは可能であれば使わない
    • ID/パスワードのみの認証となるため文字長は長いが鍵よりは強度が落ちる
    • 可能な限りRSAキーを発行して利用する(IDE等の都合で難しい場合には必須ではないが、その場合は特に権限に注意する)
  • IAM発行者と開発者を分離する

その他開発に関わる内容

まとめ

AWSセキュリティベストプラクティスを実践するに当たっていくつか抜粋して解説・補足してみました。

少しでもイメージが伝わっていたら幸いです。これを機に環境を見直してみてはいかがでしょうか?