AWSを使うなら見ておきたいチェック項目20選
AWSを実務で触られている方で「セキュリティ対策はばっちしだ💪」と言い切れる人はどれくらいいるでしょうか。特に創業間もないベンチャー企業や内製化直後のエンジニア組織の場合、サービスローンチや追加機能開発がビジネス上の最優先事項になってしまい、セキュリティ対策などの非機能要件のレビュー、設定などは後回しにされがちです。
そこで今回は、"時間がない人"でも注意したいセキュリティ脆弱性を生みやすい設定や設計の凡ミス集をまとめてみました。また、参考になりそうな記事も併せて紹介しています。
ご注意ください
筆者はAWSリソースに関するセキュリティの専門家ではありません。また本記事では、最低限の内容にとどめているためより詳細な内容は、公式ドキュメントや以下の資料をご覧ください。
1. IAM ポリシーの広すぎる権限
IAMポリシーに適切でない広い範囲の権限を付与すると、権限の乱用やデータ漏洩につながる可能性が高まります。例えば、読み取り専用ユーザーに書き込み権限を付与するといった状況が該当します。IAMポリシーを作成する際は、最小権限原則に基づいて、必要最低限の権限を持つポリシーを適用しましょう。IAMの制限には、AWS Permission Boundaryで利用者の権限を制限することもおすすめです。
// 極端な例（全リソースを許可）
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*", // 全アクションを許可
"Resource": "*" // 全リソースを許可
}
]
}
2. 個別のユーザーにポリシーを直接付与する
個別のユーザーにポリシーを直接関連付けると、過剰な権限を誤って付与するリスクがあります。また、ユーザーごとにそれぞれ異なる権限が付与されている場合、個々のユーザーが何のアクセス権限を持っているかを把握するのが困難になります。一般的なベストプラクティスはIAMポリシーをIAMグループに関連付け、ユーザーをそれらのグループに追加することです。これにより、特定の役割または職務に基づいて権限を効果的に管理でき、権限の変更を一元的に行うことができます。
3. IAMの秘密アクセスキーを共有または適切に管理しない
秘密アクセスキーの共有や不適切な管理は、セキュリティ侵害を招く原因です。アクセスキーは個人ごとに発行し、定期的なローテーションを行うなど、適切な管理を心がけましょう。また、SSH接続する場合は、可能な限りSession Managerを利用することが推奨されます。同リソースを利用する事でIAMによる権限制御ができます。
4. ルートユーザーアカウントを頻繁に使用
ルートユーザーアカウントを日常的に使用すると、セキュリティが低下します。代わりに、IAMユーザーとロールを使用し、権限を適切に分散させてください。また、Rootアカウントのアクセスキーを使用すると、もしキーが漏洩した場合、AWSアカウント全体が危険にさらされます。rootユーザのアクセスキーはできるだけ削除した方が良いです。
5. マルチファクタ認証 (MFA) を無視
MFAを設定しないと、ユーザーのパスワードが漏洩した際に悪用されるリスクが高まります。特に、管理者権限を持つアカウントはMFAを有効化し、セキュリティを強化することが重要です。
6. S3バケットを外部にも全公開してしまう
S3バケットを誤って一般公開してしまうと、機密データが漏洩する危険性があります。また、バケットにアクセスできるユーザーのIAMポリシー設定も重要です。アクセスコントロールリストとバケットポリシーを適切に設定し、S3バケットの公開範囲を限定してください。IAM Access AnalyzerやTrusted Advisorを利用することで、外部共有されているリソースの有無をモニタリングすることができます。
7. RDSインスタンスをインターネットに直接公開
RDSインスタンスを公開することで、データベースへの不正アクセスが増える可能性があります。VPC内に配置し、セキュリティグループで限定したアクセスのみを許可してください。ただし、要件によってはデータベースをホストしているVPC外のEC2インスタンスや他のリソースに接続する必要もあるかと思います。その場合はセキュリティグループを正しく設定してください。
8. セキュリティグループのルールが緩すぎる
セキュリティグループのルールが緩すぎると、不正アクセスされるリスクが高まります。例えば、インバウンドの設定で、全IPアドレスからSSHアクセスを許可する、無闇にポートを公開してしまうと、攻撃者に狙われやすくなります。最小限の通信のみを許可するように設定してください。
{
"SecurityGroups": [
{
"GroupId": "sg-xxxxxxxx",
"IpPermissions": [
{
"IpProtocol": "tcp",
"FromPort": 22,
"ToPort": 22,
"IpRanges": [
{
// 全てのTCPポートが外部に対して公開してしまっている
"CidrIp": "0.0.0.0/0"
}
]
}
]
}
]
}
9. ネットワークACLを適切に設計しない
ネットワークACLの不適切な設計は、不正なトラフィックの侵入を許してしまう可能性があります。サブネット設定の際に、特定のIPアドレス範囲からのアクセスのみを許可するなど、ネットワークACLを適切に設計してください。
{
"NetworkAcls": [
{
"NetworkAclId": "acl-xxxxxxxx",
"Ingress": [
{
"RuleNumber": 1,
"Protocol": "6",
"PortRange": {
"From": 0,
"To": 65535 // ポート範囲の終端
},
"CidrBlock": "0.0.0.0/0", // 全IPの流入を許可
"RuleAction": "allow"
}
],
"Egress": [
{
"RuleNumber": 100,
"Protocol": "6",
"PortRange": {
"From": 0,
"To": 65535
},
"CidrBlock": "0.0.0.0/0", // 全IPへ抜けられる
"RuleAction": "allow"
}
]
}
]
}
10. VPCエンドポイントポリシーを適切に設定しない
VPCエンドポイントポリシーが緩いと、不必要なサービスへのアクセスが許可される可能性があります。ポリシーを厳格に設定し、最小限のアクセスのみを許可してください。エンドポイントの作成時にエンドポイントポリシーを指定しない場合、サービスへのフルアクセスを許可する次のポリシーがアタッチされてしまいます。
// VPC内から全てのアクション（読み取り、書き込み等）が全てのリソースに対して許可されてしまっている。
{
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "*"
}
]
}
11. CloudFrontのオリジンに適切な保護を設定しない
CloudFrontのオリジンに対するアクセス制御を怠ると、不正なユーザーがオリジンのリソースにアクセスするリスクがあります。例えば、オリジン側のセキュリティグループ設定が適切でない、オリジン側のS3バケットがパブリックに設定されている、オリジンアクセスID(OAI)を設定して保護できていないなどのケースがあります。
12. AWS WAFを適切に設定しない
AWS WAF (Web Application Firewall) を適切に設定しないと、Webアプリケーションが一般的なWeb攻撃（例: SQLインジェクション、クロスサイトスクリプティング）に対して脆弱になります。 あわせて、AWS Shieldを利用するとDDoS攻撃への対策になります。
13. ソフトウェアとライブラリを定期的に更新しない
定期的なソフトウェアの更新を怠ると、セキュリティの脆弱性が悪用される可能性があります。Amazon Linux 2などのOSでSystem Manager Patch Managerを使って自動的なパッチ管理を利用するか、手動で定期的に更新してください。
14. AWS Configを有効化しない
AWS Configを無効にしていると、AWSリソースの設定変更が追跡されず、ポリシー違反や不正な変更を検出するのが難しくなります。AWS Configを有効化し、適切なルールを設定することで、リソースの設定変更を監視し、セキュリティポリシーに準拠しているか自動的に評価します。これにより、異常や違反があった場合に迅速に対応することができます。AWSアカウントを実務で利用する方は、まず設定していて損はありません。
15. CloudTrailを有効化しない
CloudTrailを無効にすると、ユーザーのAPI呼び出し履歴がトラッキングされなくなり、セキュリティ監査が困難になります。CloudTrailは有効化し、適切なS3バケットにログを保存してください。
16. アプリケーションのクレデンシャル情報を適切に管理しない
アプリケーション側で利用する環境変数、シークレット等はAWS Systems Mnager Parameter Store, AWS Secret Manager等を利用して適切に管理しましょう。認証基盤として, Amazon Cognitoが利用できると自前で実装しなくて済むので安全です。
17. ECRのイメージスキャンの脆弱性を無視する
Amazon Elastic Container Registry (ECR) では、Dockerイメージの脆弱性スキャンが可能です。これはコンテナイメージに潜むセキュリティ脆弱性を特定するのに非常に役立ちます。ECRのイメージスキャンを活用して脆弱性を検出した場合、それを無視するのは大きなリスクです。また、Amazon Inspectorを使った拡張スキャン方法を利用することもできます。
18. CloudWatch Logsにログを出力しない
AWS CloudWatch Logsを活用して、アプリケーションやシステムのログを中央で監視することが重要です。これを行わない場合、セキュリティ侵害やシステムの異常な動作に気付くのが遅れる可能性があります。手前味噌ではありますが、以下の記事も参考にしてみてください。
19. 脆弱性診断ツールを有効化していない
AWS などのクラウド環境では、セキュリティ診断ツールの利用が不可欠です。これらのツールは、システムの脆弱性をスキャンし、セキュリティのベストプラクティスに従っているかを評価します。一般的なセキュリティ診断ツールには、Amazon Inspectorや AWS Security Hubなどがあります。特に、Security Hubは、AWSのセキュリティリソースや外部ツールなどとも連携ができるため、ぜひ有効にすることをお勧めします。ただし、自動的に有効になるAWS Configルールによる料金増は注意が必要です。
20. セキュリティインシデントを検知するためのリソースを有効化していない
セキュリティインシデントの迅速な検知は、問題を早期に解決し、悪影響を最小限に抑えるために不可欠です。AWSでは、悪意のあるアクティビティを検知するAWS GuardDuty, S3バケットに保管された機密情報を監視するAmazon Macieなど、インシデント検知に特化したサービスが提供されています。
21. セキュリティインシデント対応プランを持っていない
事前にセキュリティインシデント対応プランを整備しておくことで、セキュリティインシデントが発生した場合に迅速かつ効果的に対応することができます。プランには、通知手順、対応チーム、緊急連絡先などが含まれるべきです。