More than 1 year has passed since last update.

業務でAWSを利用する時に知っておくべきポイント10選

819

Last updated at 2024-03-24Posted at 2024-02-10

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年間	「不当利得返還請求」等民法上の請求権期限、および総勘定元帳の保管期限