2024年1月時点のAWSベストプラクティスに従って作成しました
好評でしたら続編も検討します
1. 環境ごとにアカウントを分離する
本番、検証、開発ごとにアカウントを分割しましょう
✕良くない例
◎良い例
- 最初にアカウント分割しておかないと、後で分割するのはとても大変です
- アカウントを分割することで「検証と思って作業したら、実は本番だった」のような事故を減らすことができます
- コストがアカウント単位で集計されるため、環境ごとのコストを簡単に算出することができます
- AWS Organizationsを使用することで、各環境に応じた権限設定が簡単にでき、ガバナンスを強化することができます
- AWSアカウントはAWS Control TowerのAccount Factoryを使用することで、クレジットカード情報を都度入力することなく簡単にアカウントの払い出しが可能です
また、AWS Control Towerでアカウントの払い出しを行うと、各環境のCloudTrailやConfigの設定が自動で行われ、それらのログはログ集約用のアカウントに自動的に配信されます（操作できるリージョンを限定する機能もあり便利です）
AWS Control Towerを使用するときはメールアドレスの登録が必要ですか、同じメールアドレスの使いまわしができないため、Gmailのエリアス機能を使うと便利です
2. MFAを有効化する
MFAは必ず設定しましょう
- AWS社からMFAを必須化する方針が出されていますが、必須化を待たずに必ず設定しましょう
- ログインするAWS環境が多い場合は、IAM Identity Centerを使用することでを1つのMFAで複数のアカウントのログイン可能です
- IAM Identity CenterではMFAデバイスとしてMacBookのTouchIDや、Windows Helloに対応しているので、ログインに時間をかけたくない人は利用しましょう
3. リソースをコード化する（IaC）
可能な限りリソースのコード化を検討しましょう
私が以前関わっていたプロジェクトではマネージメントコンソールからリソースを作成し、画面のキャプチャを取りながら構築手順書を作成していました
しかし、マネージメントコンソールのUIが変わったり、設定値が増えたりして、気づかない間に構築手順書が使えなくなりました
IaCのメリット
- コードレビューができる
- コードをGitで管理すれば、リソースの変更履歴を見ることができる
- 環境の複製や、再作成が簡単にできる
主なIaCツール
| ツール | 言語 | メリット |
|---|---|---|
| Terraform | HCL | GCP、Azureなどでも使用可能 ネット上に情報が多い |
| CloudFormation | YAML,JSON | 学習コストが低い 対応しているリソースが多い |
| AWS CDK | TypeScript,Go,JavaScript, Python,Java,C# |
使い慣れた言語で実装可能 AWSの有識者内で盛り上がっている |
リソースが簡単に作成・削除できる分、ご操作も起こりやすいです
ご操作防止の設定を加えたり、事前にルールを決めたりしましょう
4. セキュリティサービスを有効化する
AWS社は、セキュリティをAWSにおける最優先事項であると明言しています
- CloudTrail, Config, Security Hub, GuardDutyなどは全リージョンで有効化することが推奨されています
- Security Hubはセキュリティスコア100%を目指しましょう
- Security Hubのセキュリティ基準を全て有効化してしまうと運用が大変になりますので、”AWS 基礎セキュリティのベストプラクティス v1.0.0“ から始めましょう
- セキュリティサービスを全て有効化したとしても、インシデントは起きます
セキュリティサービスを有効化しておかないと調査が難航します
仮にインシデントが発生した場合は、セキュリティのプロフェショナルでない限り、すぐにAWSサポートに問い合わせしましょう - 経験上これらのセキュリティサービスを全て有効にしても、全体コストの5%未満で導入可能です
- CloudFrontやRoute53などインターネットに面したサービスで自動導入されるAWS Shield Standardは無料で使用できます
ただし、AWS Shield Advancedにアップグレードすると、月額3000ドルのコストがかかるため注意してください
5. アクセスキーをコードに記述しない
アクセスキーをコードに記述せず、IAMロールをアタッチしましょう
AWSの試験でよく出題されるやつですが、実際にこれをやっているプロジェクトを見たことがあります
✕良くない例
◎良い例
- アクセスキーの漏洩により多額な請求が発生します
プログラムからAWSのサービスにアクセスする要件がある場合は、EC2などにIAMロールをアタッチしましょう - 開発中やPoC中など、やむを得ずアクセスキーを使用する場合があります
誤ってコミットしないようにgit-secretsの導入を検討しましょう
6. パブリックサブネットにサーバを置かない
EC2、ECS、DBはプライベートサブネットに配置しましょう
✕良くない例
◎良い例
- パブリックサブネットとはインターネットゲートウェイ（IGW）へのルートがあるサブネットです
一方、プライベートサブネットはインターネットゲートウェイへのルートがないサブネットのことです - サーバ1台構成であっても、サーバの前にロードバランサを配置し、サーバとDBはプライベートサブネットに配置しましょう
- サーバからインターネット上のサービスに接続する要件がある場合は、パブリックサブネットにNAT ゲートウェイを配置しましょう
- サーバからS3などAWSサービスに接続したい場合、かつ転送量が大きい場合はVPCエンドポイントを検討しましょう
7. ルートアカウントは使用しない
通常の開発においてルートアカウントは不要なので、MFAを設定し使用は避けましょう
ルートユーザのアクセスキーはない状態（削除）しましょう
ルートユーザとは
- 特権ユーザで、全AWSサービスとリソースに無制限のアクセス権限を持つ
- AWSアカウントの解約やサポート契約の変更などが可能
IAMユーザとは
- 日常作業に利用するユーザのことで、IAMの機能で簡単に作成・管理できる
- 管理を容易にするためにユーザはグループ（IAMグループ）に所属できる
- 事前に許可されたアクセス権限（IAMポリシー）の範囲で操作可能
もしルートユーザが乗っ取られると
- AWSアカウントのrootメールアドレスが変更され、ログインができなくなる
- AWSアカウントが解約され、構築したシステムが無くなってしまう
- コインマイニングなど、リソースの不正利用による高額請求が発生する
8. ログは最低1年間は保存する
CloudWatch LogsやS3に出力したログは最低でも1年間は保持しましょう
ログ保管期間の参考になる法令やガイドラインは下記になります
顧客側の社内ルールなども加味して、適切な期間を設定しましょう
| 保存期間 | 参考になるガイドライン |
|---|---|
| 1ヶ月間 | 刑事訴訟法 第百九十七条 ３「通信履歴の電磁的記録のうち必要なものを特定し、三十日を超えない期間を定めて、これを消去しないよう、書面で求めることができる。」 |
| 3ヶ月間 | サイバー犯罪に関する条約 第十六条２「必要な期間（九十日を限度とする。）、当該コンピュータ・データの完全性を保全し及び維持することを当該者に義務付けるため、必要な立法その他の措置をとる。」 |
| 1年間 | PCI DSS監査証跡の履歴を少なくとも1年間保持する。少なくとも3ヶ月はすぐに分析できる状態にしておく NISC「平成23年度政府機関における情報システムのログ取得・管理の在り方の検討に係る調査報告書」政府機関においては1年間以上保存 SANS 「Successful SIEM and Log Management Strategies for Audit and Compliance」1年間のイベントを保持できれば、概ねコンプライアンス規制に適合する |
| 18ヶ月間 | 欧州連合（EU）のデータ保護指令 |
| 3年間 | 不正アクセス禁止法の時効 脅迫罪の時効 |
| 5年間 | 内部統制関連文章、有価証券報告書とその付属文章の保存期間 電子計算機損壊等業務妨害罪の時効 |
| 7年間 | 電子計算機使用詐欺罪の時効 詐欺罪の時効 窃盗罪の時効 |
| 10年間 | 「不当利得返還請求」等民法上の請求権期限、および総勘定元帳の保管期限 |
※上記ガイドラインはIPAが要約した資料から抜粋したものです
https://warp.da.ndl.go.jp/info:ndljp/pid/11440710/www.ipa.go.jp/files/000052999.pdf#page=64
9. DBなどの接続情報をコードに記述しない
セキュリティの観点から、DBなどの接続情報・認証情報は、Secrets ManagerもしくはParameter Storeに保存しましょう
✕良くない例
◎良い例
- DBなどの接続情報はSecrets Managerに保存し、プログラムではこれらの情報を環境変数から取得するようにしましょう
- 環境に応じて変更が必要なURLなどもSecrets Managerで管理できれば、ビルド時に環境差異を意識する必要はなくなります
10. サーバにログインするときはSSMを使用する
AWSで構築したサーバにログインする際は、システムマネージャー（SSM）を使用しましょう
✕良くない例
◎良い例
- 以前は、踏み台サーバ経由でEC2にアクセスする方法が主流でしたが、セキュリティリスクがあるためSSM経由で接続しましょう
- Amazon Linux系のOSにはSSMエージェントがプリインストールされているため、インストールは不要です
- SSMポートフォワーディングを利用することで、ローカルのDBクライアントから、AWS上のDBへアクセスが可能です