1. 法人のお客さまトップ
  2. クラウドソリューション
  3. コラム
  4. ゼロから始めるAWSベストプラクティス - セキュリティ 編

COLUMN

ゼロから始めるAWSベストプラクティス - セキュリティ 編

みなさま こんにちははじめまして。クラウドサービス担当の柳（ねこ） です。

前職はNTT東日本とクラスメソッドの共同出資で設立されたネクストモード株式会社に在籍し、主にAWSやセキュリティ関連のSaaSを扱うSIerをしていました。

好きなジャンルはネットワーク全般とパブリッククラウドです。

コラム初投稿ということで、本記事では実際に私が担当したお客さまよりお問い合わせの多かった「AWSのセキュリティ対策」について、AWSが提供しているマネージドサービスの簡単なご紹介とAWSベストプラクティスに沿ったセキュリティ実装の考え方を説明したいと思います。

  • AWSを扱うのが初めてで、セキュリティ対策をどうしていいか分からない
  • AWSを利用して少し経つけど、セキュリティ設定に不安がある

といった方が対象で、最後まで読んでいただくことで感じていた不安を少しでも解消していただければ幸いです。

目次：

1.セキュリティ対策の重要性
2.AWSの主なセキュリティサービス
3.AWS セキュリティ ベストプラクティスについて
4.ベストプラクティスに沿った実装例と考え方
4-1. AWS CloudTrail
4-2. Amazon GuardDuty
4-3. Amazon Inspector
4-4. AWS Config
4-5. AWS Security Hub
5.さいごに

1. セキュリティ対策の重要性

本コラムをご覧の方は、改めてシステムのセキュリティ対策の重要性は説明するまではないと思いますが、実はオンプレミスとAWSのようなパブリッククラウドのセキュリティ対策は似ているようで意外と違っていたりします。特にAWSが規定する責任共有モデルを理解したうえで、セキュリティの実装をしていかないと、思い込みで「オンプレミスではこうだったから、AWSでも大丈夫だろう」という考えで実装したAWSインフラには、ご本人も気づかないうちにセキュリティホールが多数存在しているかもしれません。

そこでAWSがガイドラインとして規定するセキュリティ ベストプラクティスを活用して、AWSでどのようなセキュリティ対策を実施していれば、より安全にインターネット上のさまざまな脅威からお客さまのシステムを守ることが可能かをご理解いただければ幸いです。

なお、AWS責任共有モデルについては、別コラムで詳細を紹介しておりますのでそちらをご参照ください。

2. AWSの主なセキュリティサービス

ベストプラクティス説明の前に、AWSが提供しているセキュリティ関連サービスについて、代表的なものをいくつか紹介します。

AWS CloudTrail

　AWS各リソースに対するAPI使用状況のロギングとモニタリングを提供

AWS Config

　AWSリソースの設定値の評価

Amazon Detective

　セキュリティに関する検出結果や疑わしいアクティビティの原因を分析、調査、特定

Amazon GuardDuty

　AWSアカウントに対する脅威の検出

Amazon Inspector

　LinuxやWindows、コンテナイメージといったOS内の脆弱性の検知と管理

AWS Identity and Access Management（IAM）

  • IAMユーザによるコンソールへのアクセスや、ロールによるAPIの呼び出し時などの認証管理
  • ポリシーによるAWSサービスやリソースの利用権限の管理

AWS Key Management Service (KMS)

　暗号化キーの生成、使用の管理

AWS Secrets Manager

　シークレット情報の管理

AWS Macie

　S3上に保存されたデータの機密情報の検出や保護

AWS Security Hub

　AWSアカウント全体のセキュリティチェックの集中管理・自動化

AWS Shield

　DDoS攻撃からのシステム保護

AWS WAF

　Webアプリケーションに対する攻撃からの保護

AWS Control Tower

　AWSアカウント環境のセットアップや管理

AWS Organizations

　AWSアカウントの一元管理

AWS Systems Manager

　AWS運用データの可視化・分析

AWS Trusted Advisor

　パフォーマンスやセキュリティの最適化

AWS Well-Architected Tool

　利用しているAWSリソースの改善

Amazon VPC

　仮想プライベートネットワークの提供

AWS Network Firewall

　VPCの高機能なネットワーク保護

AWS PrivateLink

　VPCから各AWSサービスへのプライベート接続の提供

AWS DirectConnect

　AWSへの専用ネットワーク接続の提供

AWS VPN

　AWSへの暗号化されたインターネット接続の提供

…いかがでしょうか。代表的なサービスを挙げるだけでも凄い数になります。また、AWS WAFやAmazon Inspectorといったいくつかのサービスは、同じ名前でもv1やv2のように複数のバージョンが提供され、管理画面や機能が異なるものも存在します。ここに挙げた以外にも多数のサービスが存在しますし、AWSにより日々新しい機能やサービスの追加が行われており、これら全てを把握し使いこなすことはとても大変です。

3. ベストプラクティスに沿った実装例と考え方

お客さまより「全てがベストプラクティスに沿って実装していないといけないのか？」というご質問をよく受けます。答えは必ずしもそうではなく、お客さま自身がベストプラクティスを理解した上で、どのような設定がセキュリティリスクを発生させ、どういった対策が必要かを一つ一つご判断いただくことが何よりも重要だと私は考えます。

とはいえ、いきなり全てのガイドラインを把握することは難しく、「まずはここをチェックしてみてください」といったお客さま自身での簡単な点検をご案内するケースもありますので、まずは初回コラムとして代表的なAWSセキュリティサービスから最低限利用するべきサービスをピックアップし、最新のアップデートを含めベストプラクティスとして推奨される機能の利用や設定方法について説明していきたいと思います。

4. 各AWSサービスのセキュリティ ベストプラクティス

4-1　AWS CloudTrail

  • AWSアカウントを取得してから、まず初めに行うべきはCloudTrailの有効化です。AWS上のAPIイベントを全て記録するために、全リージョンで発生したユーザ、ロール、サービスのイベント履歴の証跡を作成してください。証跡の作成手順はAWS公式ドキュメントのこちらをご参照ください。
  • ログの改ざん有無を検証するために、ログファイルの検証機能は有効化するのがお勧めです（オプション設定）

  • CloudTrailコンソール上で確認できる証跡は90日までとなります。それ以前の証跡確認が必要になることは良くありますので、必ず別のAWSサービスに保存しておくようにしましょう。保存先は①S3、②CloudWatcheLogs、③CloudWatchEventsがありますが、運用性を考慮しますと①S3に加えて②CloudWatcheLogsにも保存することを推奨します。（デフォルトではバケットやロググループには保管期間が設定されていませんので、予算に合わせライフサイクルは適切に設定してください）

    CloudWatch Logs へのイベントの送信

    ※CloudTrailロールがCloudWatcheLogsにログイベントを送信するには、こちらのロールポリシーが必要になります。

  • ただ証跡を保存するだけではなく、定期的な分析やCloudWatcheLogsのロググループにカスタムメトリクスを設定し、疑わしいイベントが検出された場合はアラートメールを送信するなど、保存だけして満足することがないよう適切に運用しましょう。AWSではいくつかのイベントを検知するためのサンプルテンプレートが提供されています。

4-2　Amazon GuardDuty

  • 有効化することでAWS CloudTrail、VPC Flowログ、DNSログを自動的に分析し脅威を検知することが可能になります。AWSアカウントをお持ちの方は必ず本サービスを有効化することを忘れないでください。
  • また、GuardDutyはAWSアカウントの全てのリージョンで有効化することを強く推奨しています。メインで利用されているリージョンが東京でも、悪意のある者はロケーションを問わず、さまざまな手法で他リージョンのリソースやAWSアカウントへの攻撃を行ってきますので、全てのリージョンで不正なアクティビティに対する検知を行うための対策が必要です。

  • コンソールで全リージョンを一つずつポチポチ設定確認と有効化をしていくのもいいですが、少し面倒なのでaws cliで無効なリージョンが存在を確認後、一括で有効化するのが楽です。

    （前提条件）

  • コマンドを実行するIAM ユーザが所属するグループ、またはロールにはGuardDuty の有効化に必要なマネージドポリシー：AmazonGuardDutyFullAccessをアタッチしておいてください。（IAMユーザへのポリシー直接アタッチは推奨されていません）
  • Default Profileにaws cliを実行するためのIAMクレデンシャル情報が設定済みである場合のコマンド例になります。profileが別に設定されている場合は、事前にAWS cliの環境変数を変更しておいて下さい（export AWS_PROFILE=profile_name）
有効化有無の確認コマンド（非Organizationsアカウントの場合）
for REGION in `aws ec2 describe-regions ¥
			--query "sort(Regions[].RegionName)"  ¥
			--output text`
do
DETECTOR=$( ¥
			aws guardduty list-detectors ¥
			--region "${REGION}" ¥
			--query DetectorIds ¥
			--output text ¥
			)
if [ "${#DETECTOR}" -ne "0" ] ; then
		echo "${REGION}:${DETECTOR}"
else
		echo "${REGION}:-"
fi
done

コマンドの出力結果で、リージョン名の横に「-」が表示された場合はそのリージョンはGuardDutyが有効になっていませんので、以下コマンドで全リージョンを一括で有効化設定をしてしまいましょう。

有効化コマンド（非Organizationsアカウントの場合）
for REGION in `aws ec2 describe-regions ¥
			--query "sort(Regions[].RegionName)"  ¥
			--output text`
do
DETECTOR=$( ¥
			aws guardduty list-detectors ¥
			--region "${REGION}" ¥
			--query DetectorIds ¥
			--output text ¥
			)
if [ "${#DETECTOR}" -ne "0" ] ; then
		echo "${REGION}:${DETECTOR}"
else
		aws guardduty create-detector ¥
			--region "${REGION}" ¥
			--enable
fi
done

  • 2022/07に Amazon GuardDutyへ待望のマルウェア対策機能が追加されました。これにより今まではEC2やECSのマルウェア対策として、別途セキュリティソフトを購入したり、Marketplaceでエージェントが含まれたAMIを導入するなどの対応が必要でしたが、この機能を有効化することにより簡易的なマルウェアの検知が行えるようになりました。

    ※Amazon GuardDuty Malware Protectionが追加される以前にGuardDutyを有効にしていたAWSアカウントは、改めてAmazon GuardDuty Malware Protectionを有効に設定する必要があります。（Malware Protection実装後にGuardDutyを有効化した場合は、Malware Protection設定も自動で有効化される模様です）

  • ベストプラクティスとして本機能の利用を推奨するような公式アナウンスは今のところ確認できませんが、エージェントの導入も不要、かつ面倒な設定が不要でとても便利な機能に見えます。ただし注意点としては以下が挙げられます。

    • スキャン対象としてはEBS(EC2だけでなくECSやEKSも対応)になりますが、制約として容量が1TB未満までに限られるようです。1TBを超えるEBSの場合は、今までと同様のマルウェア対策が必要となりそうです。
    • スケジューリング機能はなく、EC2などで不審な動作がGuardDutyにより検知された場合のみ、自動的にEBSのスナップショットを作成→別EBSとして復元したうえでスキャンを行う仕様となります。
    • 実際にマルウェアが検出されたときの動作は隔離や駆除といった一般的なセキュリティソフトに実装されているものではなく、GuardDutyへの検出通知を行うのみとなっています。そのため感染以前の状態に戻すにはバックアップからEBSを復元するか、別途セキュリティソフトによる駆除などが必要になりますので、現時点の仕様ではあくまでも簡易的な検知が可能になったものと捉えたほうが良さそうです。

4-3　Amazon Inspector

  • Amazon Inspectorは、EC2のOS内やECRにプッシュされたイメージを定期的に自動スキャンし、潜在的なセキュリティリスクを発見することに役立ちます。OSカーネルに潜む脆弱性だけでなく、例えばSSH 経由の root ログインを無効化しているか、パスワードの規則性は安全な設定になっているかといったOS以外のセキュリティリスクもチェックしてくれます。

  • また、最新のアップデートではLambda についても自動スキャンの対象となり、Lambda 関数コードで使用されるアプリケーションパッケージの依存関係におけるソフトウェアの脆弱性を発見できるようになりました。
  • Amazon Inspectorはv1(classic)とv2が存在し、classic版では少し面倒な設定が必要でしたが、v2ではとてもシンプルになりAWSコンソールから有効化ボタンを押すだけでアカウント内のサポートされているAWSリソースが自動的に検出対象としてアクティブ化されます。

  • 評価内容についてですが、標準でルールパッケージと呼ばれる検査項目が用意されており、主にネットワークの到達可能性評価とホスト評価の2つの項目で評価されます。こちらの記事でも特徴や料金の注意点などがまとめられていますので、あわせてご参照ください。ルールパッケージについては、それぞれ以下の内容となっています。

  • アップデートによりLinuxに加えWindows Serverにも正式に対応するようになりましたが、OSバージョンによってはいくつかのルールがサポート対象外となっています。OSごとの詳しい対応状況については、以下をご参照ください。

    https://docs.aws.amazon.com/ja_jp/inspector/v1/userguide/inspector_rule-packages_across_os.html

  • OSなどのアップデートをしていない状態やデフォルト設定のままでEC2を運用していると、かなりの数のリスク指摘を受けることが予想されます（中には対応不要な指摘も存在します）。一つ一つ全ての指摘事項を丁寧に対応しているととても時間がかかりますが、完全放置はリスクが高いです。

    AWSの責任共有モデルでは、OSのセキュリティ管理はユーザ自身が行うことになっていますので、是非Amazon Inspectorを導入し潜在的なセキュリティ上の問題への対処を行ってください。

4-4　AWS Config

  • AWS Config を使用すると、AWS リソースの設定を監査し、Center for Internet Security (CIS) が推奨する業界のベストプラクティスに準拠することができます。GuardDuty 同様、通常利用のリージョンに加え、未使用のリージョンに対しても意図しないリソース変更を検知する目的で、AWSアカウント内で利用可能な全てのリージョンで有効化することを推奨しています。実際にアクセスキーの流出により、他国のリージョンへリソースを作られてしまったケースも存在しますので、そういった場合にも備え全リージョンを記録対象としましょう。
  • AWS Config に記録する必要があるリソースタイプとして [すべてのリソース] を選択してください。
  • IAMなどのグローバルリソースは、一つのリージョンでのみ記録する設定を推奨します。
  • AWS Config が記録するリソースの詳細はS3バケットに保存されますが、そのバケットは必ずパブリック非公開である必要があります。
  • 特定のルールやリソースタイプのコンプライアンスの変更はSNSトピックに通知するようにします。サポートされているリソースタイプはこちらを参照してください。
  • 1 日 1 回以上の頻度で定期的なスナップショットをオンにし、アカウント内のすべてのリソースの最新設定状態をバックアップします。
  • AWS Configを有効化するだけでなく、AWS Config の管理またはカスタムルールと修正アクションを使用した汎用コンプライアンスフレームワークである、適合パックテンプレートの利用を検討してみましょう。（長くなるので詳細はまた別のコラムで説明します）

4-5　AWS Security Hub

  • 前提条件となるAWSConfigの有効化が済みましたら、あわせてAWS Security Hubも有効化することを推奨しています。AWS Security Hubは主に２つの機能があり、コンプライアンス基準に沿ったセキュリティチェックを行ってくれる機能と、前述したAmazon InspectorやAmazon Guard Dutyなどの サポートされているAWS サービス、およびAWS パートナーネットワーク (APN) セキュリティソリューションからのセキュリティ結果データを集約する機能を備えた、とても便利なサービスです。

  • Security Hubの検出結果は、Amazon Event Bridgeと組み合わせることにより、自動応答や自動修復といった、人の目を介さないアクションを起こすことも可能ですが、検出結果のレポートが見られるようになるだけでも十分効果はありますので、まずはSecurity Hubを有効化したうえで、定期的にレポートの確認を行う運用をしましょう。

    なお、AWS Organizationsと統合されたAWSアカウントでは通常自動的に有効化されますが、未統合の場合は手動で有効にする必要があります。Security Hub を有効にするためには、Security Hub マネージドポリシー：AWSSecurityHubFullAccess をIAM グループ、またはロールに付与してください。

  • クロスリージョン集約により、複数リージョンの結果を一つのリージョンに集約・管理することもが可能です。前述したとおり、AWSConfigやAmazon GuardDutyを複数リージョンで有効化している場合は管理が非常に容易になりますので、是非ご活用ください。
  • Security Hubのセキュリティ標準ルールは、「AWS基礎セキュリティのベストプラクティス」「CIS AWS Foundations Benchmark v1.2.0」「PCI DSS」の3つに加え、2022/11/9 に「CIS AWS Foundations Benchmark v1.4.0」のサポート追加が発表され、その後も「NIST Special Publication 800-53 Revision」のサポート発表と続々とルールが追加されています。

  • 「PCI DSS」はクレジットカード業界のセキュリティ基準ルールになりますので、該当しないシステムの場合は無理に適用する必要はありません。「AWS基礎セキュリティのベストプラクティス」「CIS AWS Foundations Benchmark (※)」の２つを適用していれば、スタンダードな構成においては十分かと思います。

    ※CIS AWS Foundations Benchmark v1.2.0ではAWSでも推奨されていなかったルールも存在していたため、v1.4.0のみの適用で問題なさそうです。CIS AWS Foundations Benchmark v1.2.0からv1.4.0の差分はこちら。

  • それぞれのルールでコントロールされるカテゴリについては、以下サイトを参照してください。

  • Security Hubを有効化後は、最大で24時間経過後に概要ページでセキュリティスコアが表示されるようになります。重要度により対応有無の判断が必要かと思いますが、最低でも重要度がCRITICAL～HIGHの項目については、設定値を見直しましょう。

5. さいごに

今回は最低限ご利用いただきたいセキュリティサービスに絞ってご紹介しましたが、まだまだ説明したいサービスが多数ありますので、別コラムでも続きを紹介できればと思います。

もしAWSのセキュリティについてご不安な点やご心配なことがありましたら、NTT東日本が提供するAWSセキュリティチェックでも、お客さま環境の診断や修正設定が可能ですので、お気軽にお問い合わせください。

カテゴリー

RECOMMEND
その他のコラム

ページ上部へ戻る

相談無料！プロが中立的にアドバイスいたします

クラウド・AWS・Azureでお困りの方はお気軽にご相談ください。

クラウド予算計画のご相談
クラウドの成功事例を見る