セキュアなワークロードとアプリケーション

VPC の中の通信を止めたり通したりする仕組みは 2 つある。どちらも「許可するルールを書く」ように見えるが、動きが正反対だ。

設計の基本形は決まっている。外から受けるものだけをパブリックサブネットに置き、残りはプライベートに置く。典型的な 3 層（Web・アプリ・DB）はこうなる。

• ロードバランサーだけがパブリックサブネットに立つ。
• アプリのサーバーはプライベートサブネットに置き、ロードバランサーの SG からだけ受ける。
• データベースはさらに奥のプライベートサブネットに置き、アプリの SG からだけ受ける。
• 外へ出る通信（更新の取得など）は NAT ゲートウェイ経由にする。

では、プライベートサブネットのサーバーにログインして作業したいときはどうするか。昔は踏み台サーバー（Bastion）をパブリックに置いたが、今の正解は AWS Systems Manager の Session Manager だ。

攻撃の種類によって、当てる道具が違う。量で押してくる攻撃（DDoS）と、中身が悪い攻撃（SQL インジェクション）は別の層で止める。

データベースのパスワードや API キーをソースコードや環境変数に直接書くのは誤りだ。AWS には預け先が 2 つある。

プライベートサブネットの EC2 から S3 を読むとき、NAT ゲートウェイ経由でインターネットへ出て S3 のエンドポイントへ行く、という経路になる。これは遅く、高く、外へ出ている。VPC エンドポイントを使うと、AWS の内部だけで届く。

オンプレミスのネットワークと VPC をつなぐ方法は 2 つある。速さと安定を金で買うか、既存のインターネット回線で済ませるかの違いだ。

検出系のサービスは名前が似ていて混ざりやすい。何を入力にして、何を出すかで覚えると分かれる。

シナリオ演習

プライベートサブネットの EC2 から S3 へ毎日大量に書き込んでいる。NAT ゲートウェイのデータ処理料が月々の請求で目立つようになった。どう直すか。

ゲートウェイ型は無料で、通信が AWS の内部で完結するのでデータ処理料が消える。NAT を増やす・インスタンスを大きくする案は、どちらも費用が増える方向。

シナリオ演習

Web アプリが SQL インジェクションを受けた。同じ攻撃を止めたい。

Shield は L3 / L4 の DDoS（量で押す攻撃）が対象で、リクエストの中身は見ない。セキュリティグループはポートの話なので、正規の 443 番で来る攻撃は止められない。