AWS Verified Access で VPN なしで Web アプリケーションに安全にアクセス
最近、AWS Verified Access というサービスが GA となり、これを使うと VPN なしで Web アプリケーションに安全にアクセスできるというものです。
特に、VPN 以外の方法で、社内向け Web アプリに安全にアクセスさせる手段として使えそうです。VPN の管理が必要なくなり、社内で使われている Azure AD などの認証基盤を経由してユーザがアクセスできるので、ユーザ体験としても良いと思いました。
すでに、いくつか試してみた記事があったので紹介します。
- Azure AD を ID プロバイダーとする実装例
- Verified Access エンドポイントの作成等がまとまっている
懸念点としては、アクセス対象のサーバ・ALB 等をすべて private subnet に配置しないといけないという点です。既存のリソースに対して適応したいときは、インフラ構成の変更が必要となり手間かもしれません。
AWS User Notifications で GuardDuty や AWS Health イベントなどの通知設定を一元的に設定・管理可能に
AWS User Notifications というサービスが GA となりました。このサービスを使うことで、GuardDuty や AWS Health イベントなどの通知設定を一元的に設定・管理が可能となります。
今までバラバラに設定・管理していたのを、User Notifications を使って一元管理できるとスッキリしそうですね。
- [新サービス] AWS User Notifications で通知設定を試してみた | DevelopersIO
- AWS User Notifications の高度なフィルターを使って通知するイベントを絞ってみた | DevelopersIO
通知先としては、メール、AWS Chatbot、AWS モバイルアプリケーションに対応しています（Chatbot 経由で Slack 通知させるときにメンションを付けたいのですが、Chatbot の制約によりそこまではカスタムできないようです。）
セキュリティインシデント疑似体験 GameDay に参加してみた
ゲームを通していくつかのケーススタディを学んだのですが、いずれも GuardDuty のアラートが起点となっていて、改めて GuardDuty のアラートの重要性を痛感しました（GuardDuty は CloudTrail や VPC フローログなどから、不審な操作・アクセスを検知してくれるサービスです。）
また、そもそもログが取れていないと GuardDuty による検知ができない、アラートが発砲されても調査する材料が足りない、ということに陥りかねません。今一度、必要なログをちゃんと収集できているか確認してみることも大切です。
Security Hub と GuardDuty で予防的統制と発見的統制にしっかり取り組んでいきたいですね。
- 発見的統制
- AWS のサービスで言うと、GuardDuty による悪意のあるアクティビティや異常な動作をモニタリング & 検知がそれに該当します（怪しい動きを発見する）
- 予防的統制
- AWS のサービスで言うと、Security Hub による自動セキュリティチェックがそれに該当します（問題が起こる前に予防する）
Discussion