ネットワークのセキュリティ対策
黒曜氏：続いて、ネットワークセキュリティの話にいきましょう。ネットワークのセキュリティは、VPCを作って、サブネットを作って、SecurityGroupを作って、アタッチして……とやっていると大変です。私はそれらを手でやると穴を作るタイプなので、Copilot CLIというツールを使い、そちらに一任しています。そうすれば安全かつ楽にできると思います。
Copilot CLIを知らない方もいるかもしれないので紹介すると、主にECS（Elastic Container Service）でのコンテナ運用に使える、AWSのツールセットです。ECSだけではなく、最近でいうとApp Runnerやデプロイパイプライン、CodePipelineで組むところまで、全部コマンドラインからワンストップでできます。manifest.ymlというファイルに設定を書いておくと、そこから作ってくれるというIDaaS的なこともできるので、これは個人的に推しているいいツールです。
Copilot CLIで構築した環境はスライドのようなかたちになります。ALB（Application Load Balancer）がHTTPリクエストを受けて、パブリックサブネットを作ったものの中でECS Serviceが2つ立ち上がり、それぞれでコンテナが立ち上がっている。コンテナはECR Registryにあるものを引っ張ってくる。Copilot CLIだとこういった構成を簡単に作れるので、いいと思っています。
このように構築した環境のいい点は、VPCとサブネットだけではなくALBやECSそのもの、あるいはそれに紐づけるセキュリティグループみたいなものも自動で作ってくれることです。
ECSの受けられるリクエストとは、ALBからのアクセスしか受け付けないようなセキュリティグループの設定です。ここに任せておけば最低限のガードレールはできるので、すごく楽ができます。
また、先ほど言ったとおり、ECS on Fargateで組むことによってEC2を直接持たなくていい。OSやミドルウェア更新は気にせず、イメージさえちゃんとしていればいいので、かなり楽です。昔はECSにした時に本番作業がつらいことがありましたが、最近ではECSにdocker execできるようになりました。
Copilotもそれをサポートしていて、copilot svc execというコマンドを使うとSSH（Secure Shell）ライクな作業もコンテナに入って可能になるので、このあたりの不便さはほとんどないと思います。
今はApp RunnerもCopilot CLIに対応していて、そちらを使うとALBもAWSマネージドになるので、もっと持ち物を減らして楽ができると思います。ただし、App RunnerはWAFには未対応という課題があるので、弊社ではまだECSのままにしています。ネットワークの話は以上です。
Webアプリのセキュリティ対策
続いて、Webアプリのセキュリティの話をします。一般的な対策がいくつかあるとは思いますが、AWSレイヤーでもいくつかやることがあります。まず、AWSのWAF（Web Application Firewall）を挟んで典型的な攻撃を到達前にブロックしています。
基本的なマネージドルールだけ適用して、標準リクエストで引っかかるようなポイントは個別に許可ルールを設定し、最低限の運用にしています。これだけでも相当な数のリクエストを弾いているので、入れておくといいと思います。
また、ECRのコンテナイメージスキャンは数クリックで有効にでき、これを有効にしておくだけで脆弱性の分類などを見られるようになるので、その定期的なチェックだけはしています。AWSと関係ないところでは、GitHubのDependabotでセキュリティアラートを出したり、「VAddy」という脆弱性検査ツールで定期的に脆弱性の検査を行ったりして運用しています。
（スライドを指して）今回はAWSに関係のある上の2つについてもう少し細かく話します。AWSのWAFです。WAFにはいろいろなルールセットがあってどうすればいい迷いましたが、WafCharmが出しているブログ記事に、「AWSのWAFはこれを有効にするといい」というおすすめめセットがあったので、これらを有効にしています。
今なら、一番左のRequiredに、Core Rule Set、Known Bad Inputs、SQL Database。Amazon IP Reputationは昔なかったので入っていません。その4つを有効にするといいと書いてあります。
（スライドを指して）実際の設定画面はこのようになっていて、CommonRuleSet、KnownBadInputs、SQLRuleSetの3つ。それと、IP Reputationを足していないので足さないといけません。
WAFは誤検知で引っかかるケースがあるので、それをホワイトリストで許可するためのルールが一番上にいるかたちで運用しています。
（スライドを指して）実際にどういうリクエストが来てブロックされているかがこちらです。ここにあるものは全部「NoUserAgent_HEADER」ですが、「/robots.txt」や「/api/v1/time」といった、いかにもなURI（Uniform Resource Identifier）が並んでいます。
このようなゴミリクエストが来て、単純に脆弱性につながらないまでも微妙な負荷がかかったり、アクセスログを汚したりするかもしれないので、アクセス数がよほど多くない限りはWAFを挟んでおいたほうがいいと思います。
ちなみに、WAFを普通にアプリケーションで使っていると、たまにうっかりブロックされます。特にリダイレクトURLが入っていると、それがトラバーサルのパスに見えて引っかかったりするので、そういう場合は個別にホワイトリスト化する必要があります。
そもそも気づかないとホワイトリストに載せられないので、現在はAWSのWAFがブロックしたタイミングでSlackに通知して、False Positiveなブロックがないかをチェックして、False Positiveなものがあればホワイトリストに入れる運用をしています。
逆にブラックリストというか、明らかにダメなパターンのルールについては、Lambdaのレイヤーで弾いて、以降ムダな通知が来ないようにしています。以上がWAFの話です。
続いて、ECR（Elastic Container Registry）のコンテナスキャンの話です。ECRでコンテナスキャンを有効にしてプッシュ時にスキャンするよう設定すると、「Clair」（オープンソースの脆弱性検査ツール）でスキャンした結果をスライドのように見られます。
「Critical 1」や「High 4」と出てきて、こちらもまたCriticalがあるじゃないかと。「CVE（Common Vulnerabilities and Exposures）はFalse Positiveにもわりと出る」と、DockerのFAQにも書いてあります。
例えばカーネルの脆弱性の場合、Dockerのカーネルはホストと共有でイメージの中のものは使われず、False Positiveで引っかかるものもたくさん出てくるので、これについては全部クリアにするものではないとFAQに書いてあります。
CVEでは「なにが出ているか」よりも推移が重要で、新しいものが出たタイミングでチェックできるかが大事だと思います。今は定期的に見ていますが、レイヤーの脆弱性検査を重視するのであれば、AWSが提供している拡張スキャンにするとよさそうです。
こちらを有効にすると推移が見られて、新しいものが発生すると通知してもらえます。ただ、スキャン前のコストがそこそこかかるので、そこはトレードオフというところです。Webアプリのセキュリティの話は以上です。
データストアのセキュリティ対策
最後はデータストアの話です。とはいっても、ここまでのことができていればそんなに重要なポイントはありません。データストアのセキュリティは、基本的なことをちゃんとやることが大事です。例えば、RDSはパブリックアクセスを無効にする、RDSの接続元はセキュリティグループで絞る、S3はパブリックアクセスはすべてブロックする、データの暗号化を有効にする。このあたりは、Security Hubに従っていればだいたい設定されると思うので、重要度が低いわけではないですが、ほかより比較的やることが少ないと思います。というわけで、スライド1枚で終わります。
「安全に楽をする」はベストプラクティスに従うのが一番大事
ひととおり話し終えたので、まとめに行きます。最初に見せた、「どうやって安全に楽をするか」というスライドを再掲します。AWSのベストプラクティスに従うのが一番大事ということで、DevelopersIOの記事を紹介しました。Security Hubでセキュリティチェックを入れると、従っているかを継続的に見ることができて安心です。
また、なるべく管理するリソースを減らし、ツールの既定に合わせることによって楽ができると思います。例えば、Fargateを使ってEC2を持たないようにすることで、ミドルウェアやOSレイヤーのものを気にしないで済むようにしたり、ネットワークの環境構築をCopilotなどのツールに任せたりするということです。
ほかに、アプリケーションレベルでもAWSサービスで活用できるものがあるので、典型的な攻撃はWAFで防いだり、ECRのコンテナスキャンで脆弱性をチェックしたりすると便利です。
以上、弊社の事例を紹介しました。まだまだやることはあると思いますが、私はセキュリティ専門ではないので、突っ込みどころがあったかもしれません。そこはお目こぼしください。以上で私の発表を終わります。ご清聴ありがとうございました。
