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

こんにちは、臼田です。

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

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

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

熟読いただきたい資料

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

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

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

VPCの構成とアクセス制御

• 1つのシステムは基本は1つのVPCにする
  • 共存しない、分けすぎない
  • ダメな例1: 複数のシステムがVPC内で共存し、セキュリティグループ等を共有している。
  • ダメな例2: 本来外部からアクセスしない部分が外部公開されてインターネット経由でアクセスしている。
  • より適切なのはシステム毎にAWSアカウントIDを分離する
  • 参考: AWSアカウントとVPC、分ける？ 分けない？: 分割パターンのメリット・デメリット
  • 参考: 【レポート】マルチアカウント戦略におけるセキュリティとガバナンスのアーキテクチャ設計 #reinvent #SID331
• セキュリティグループがとりあえず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エンドポイントを利用する
  • インターネットを経由せずにアクセスする事が可能
  • https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-endpoints.html

IAM管理とアクセス制限

• IAMベストプラクティスに基本準拠する
  • https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html
• すべてのコンソールログイン可能なIAMユーザーに対して MFA を有効化する
• Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する
  • EC2から実行するAPIコールにはIAM Userのアクセスキーを利用しては「いけない」。必ずIAM Roleを利用する。
  • LambdaやCode系等各種サービスが利用するRoleについても同様
• アクセスキーを共有しない
  • アクセスキーは開発者毎発行されたIAM Userから一つだけ発行し、個人で利用する
  • アクセスキーはgitにコミットしない(コード内には基本的にアクセスキーは不要、IAM Roleを利用するため)
  • これを活用する: AWSアクセスキーをGitリポジトリに混入させないために git-secrets を導入した
• 複数アカウントにまたがるIAMを管理する場合にはIAM RoleによるSwitch User(Assume Role)を利用する
  • IAM Userの数を減らせるため、管理するクレデンシャルを少なくすることができる。
  • IAM Userを管理するAWSアカウントでAWSユーザを集中管理できる。
  • https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html
• CodeCommitのHTTPSクレデンシャルは可能であれば使わない
  • ID/パスワードのみの認証となるため文字長は長いが鍵よりは強度が落ちる
  • 可能な限りRSAキーを発行して利用する(IDE等の都合で難しい場合には必須ではないが、その場合は特に権限に注意する)
• IAM発行者と開発者を分離する
  • 環境により難しいが、可能であれば実施する
  • 開発者用IAM: 【Tips】Admin権限を持っていないIAMユーザでIAM Roleを設定するためのポリシー設定

その他開発に関わる内容

• アプリケーションコードは可能な限り検証と本番で一緒にする
  • 差異があるパラメータやDBパスワードの保存などはAWS Systems ManagerのParamater Storeを利用して外出しする
  • Paramater Storeを利用すればローカルからでも同じように利用することができるので開発が捗る
  • https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/systems-manager-parameter-store.html

まとめ

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

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