注目の記事

AWS再入門2018 セキュリティチェック編

2018.03.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。池田です。本州からは梅の便りが届いていますが、札幌はまだまだ雪景色です。 最近になり周囲で「今度はEchoの招待が届いた!」とか「2回目のEcho Dotの招待が届いた!」とか「2台目ゲット!」とか聞こえてきました。我が家にEcho Plusを迎え入れる日はいつになるのでしょうか。 早くスマート家電を声で制御する生活を体験したくてワクワクしています。

はじめに

今年に入ってからAWS再入門シリーズと題して勉強を進めているのですが「たまにはAWSホワイトペーパーを読んでみよう」と思い立ちいくつか読んでいた中でAWS_Security_Checklistという資料を見つけました。 内容は非常に簡潔ですが、各項目はそれぞれ関連するAWSドキュメントへのリンクが設けられていました。 そこで今回は資料からの各リンク先ドキュメントを基に筆者が整理したチェックポイントなどを「AWS再入門2018 セキュリティチェック編」としてご紹介したいと思います。 興味のある方はもちろん、社内でAWSを活用されているけれどまだ目を通したことがないという方にはぜひ、原文を読んで役立てていただきたいと思います。

Security Checklist - General

1 Protect your root account.

ルートアカウントはAWSサービスを利用する上で最も重要なアカウント情報です。そのため、特に厳格な管理を行う必要があります。 中でもルートアカウントのアクセスキーについては、個人資産や機密情報と同様な保護が推奨されています。 AWSドキュメントでも、必要でない限りは作成しないことを強く推奨されており、代替として管理権限を持ったIAMユーザの作成手段が提供されています。

2 Protect your CloudTrail and your Billing S3 Bucket.

CloudTrailおよびS3バケットに対するアクセスは、ポリシーやACLおよびIAMグループとIAMユーザの適切な制限により「必要な情報に限り」「必要な手段でのみ」許可するようにします。 これは、本来見せるべきではない情報や削除/改変/持ち出しをされてはならない情報を保護することにもなります。

3 Activate region based CloudTrail.

全てのリージョンにおいて、CloudTrailを有効にすることで、各アカウントのアクティビティ(行動)を追跡可能な状態にします。 これにより万が一のセキュリティ事故をはじめ、必要なリソースの変更や削除を行ってしまった日時やユーザの確認が可能となり、事故や障害の調査および復旧対応に役立ちます。また、これを周知することにより軽率な行動や不正行為の抑止効果も期待できます。 各種操作の記録が保存されることにより、コンプライアンス面での活用も可能となります。

4 Create administration roles with limited privileges.

管理者ロールの作成も必要な範囲の権限付与を意識して作成するようにします。各種リソースへのアクセス制御にはIAMを利用するようにします。 リクエストに対するIAMの評価論理は次のルールに基づいていることを踏まえてポリシーを定義しましょう。

  • デフォルトでは、すべてのリクエストが拒否されます。
  • 明示的な許可はこのデフォルトに優先します。
  • 明示的な拒否はすべての許可に優先します。

5 Familiarize yourself with AWS Security Token Service (STS) and roles.

AWSセキュリティトークンサービス(STS)を利用することで一時的なセキュリティ認証情報を付与できます。IAMユーザのアクセスキー認証情報とほとんど同じですが、有効期間を数分から数時間で設定することが可能という特徴を活用することでセキュリティリスクの低減効果が期待できます。 長期的な認証情報が必要な場合にはIAMロールによるアクセス権限の付与を行います。STSを利用する方が安全なのか、IAMロールを利用する必要があるのかの評価と判断することが安全につながります。

6 Familiarize yourself with AWS Detailed Billing and monitor your monthly usage regularly.

請求情報を定期的に確認することはコスト管理だけでなく、不要なリソースや不審なリソースの発見につながる場合があります。仮に新規リソースの利用を開始しておらず負荷状況も安定しているはずの期間に、想定外の利用料金が計上されていることが判明した場合は直ちに不正利用がないかを調査する必要があります。

Security Checklist – EC2/VPC/EBS

1 Only use encrypted EBS volumes.

暗号化EBSボリュームの利用を徹底することで当該インスタンスが扱うデータやスナップショットを漏洩リスクから保護します。

2 Activate your VPC Flow Logs.

VPCフローログを有効化することでVPC内のトラフィック情報を収集します。これによりAmazon CloudWatch Logsでの確認が行えますので、通信エラーや不正な通信などトラフィックに関する問題が発生した場合の調査に役立てることができます。 ただし、VPCフローログの利用にあたってはいくつかの制限事項があるので事前に確認、理解しておく必要があります。

3 Protect your EC2 Key Pairs.

EC2キーペアもアクセスキー同様に重要なものであると認識し、AWS アクセスキーを管理するためのベストプラクティスを参考に、適切な保護保管対象として扱います。

4 Leverage IAM roles for EC2.

各EC2インスタンスに対し、それぞれに必要な範囲のアクセス権を設定したIAMロール、IAMポリシーの組み合わせを適用することで、安全性を高めます。

5 Control inbound and outbound traffic to your EC2 Instances with clearly structured Security Groups.

セキュリティグループにより、インスタンスの通信を適切に制御します。不要な対象へのアクセスや、不明なリソースからのアクセス許可は思わぬトラブル発生の原因となります。

Security Checklist – S3

1 Don’t create any public access S3 buckets.

フルアクセス可能な状態でS3バケットを公開することは、データの喪失や改ざんリスクだけでなく想定外の利用料金が発生する原因にもなり得ます。それぞれのバケットに適切なバケットポリシーまたはIAMによるアクセス制御を適用することでリスク回避できます。

2 Encrypt sensitive data in S3 using Server Side Encryption (SSE).

特に重要なデータをS3バケットに保管する場合は、バケットポリシーによりServer Side Encryption(SSE)を強制する運用とします。これにより人為的ミスによるリスクを低減できます。

3 Encrypt inbound and outbound S3 data traffic.

S3 SSLエンドポイントを利用することでデータ転送時のリスクから保護します。当然、暗号化に利用する各種キーの取り扱いもアクセスキーやEC2キーペア同様、慎重に行う必要があります。 AWS Key Management Service(KMS)を利用することで高度なキー管理が実現できます。

4 Familiarize yourself with S3 Versioning and S3 Lifecycle Policies.

S3バージョン管理およびライフサイクルのポリシーを理解しておくことで、オブジェクトのバージョン管理を容易にし、ライフサイクルの適切な自動化によってコスト肥大化の抑止のほか、不要データの削除忘れから解放されます。

5 Activate S3 Access Logging and analyze logs regularly.

S3バケットへのアクセスログを有効化し、定期的に分析することはセキュリティ監査およびユーザの動向調査に役立ちます。これは適切な利用方法やデータの配置、アクセス権の見直しにも活用できます。

まとめ

冒頭でも紹介しましたが非常に簡潔な資料ながらも、適切な情報を提供してくれている非常にすばらしい内容だと感じました。AWSに限らず情報資産を扱う際には避けて通れないセキュリティの話題ですが、扱う対象とその手段によってそれぞれにベストプラクティスが存在していると思います。今回ご紹介したような簡潔にまとまったチェックリストが公開されているのは、利用していく立場にとって大変ありがたいことです。 新規にリソースを作成する際に限らず、定期的にこのリストによるチェックを行うことを実践していこうと決めました。自身の学習目的ではありましたが、この投稿がどなたかの役に立てば幸いです。