〇 「ログがない！？」、インシデント対応を混乱させかねないAWS活用の落とし穴。
ITシステムの開発や運用の経験があったとしても、AWS（アマゾン・ウェブ・サービス）の仕様について理解が不十分だったり、思い込みがあったりして落とし穴にはまってしまうことがあります。ありがちなトラブルやヒヤリハットを架空のユーザー事例として再現し、どうすれば落とし穴を避けられるかを解説します。
インターネットに公開して不特定多数がアクセスするシステムでは、サーバーのアクセスログ、開発者や運用担当者によるシステムの変更ログ、ネットワークログなどの「ログ」がとても重要です。問題が発生した場合、保存したログを分析することで、いつ、どこで、何が起こったのかを素早く特定できます。
しかし、クラウドの利用経験が浅いと、サービスの仕様を調べながらシステムを構築するので手いっぱいになりがちです。その結果、「運用開始後のトラブル時にどのログをどう確認するのか」の検討が後手に回ってしまったりします。ここが落とし穴になり、運用開始後に混乱を招く場合があります。よくあるパターンが
- ログの保存方法の検討が不十分
- どのようなログを取得できているかの把握不足
- 通信ログを取り忘れる
といったものです。
次ページからは、こうした落とし穴を避ける考え方やテクニックを、事例を介して分かりやすく説明します。事例の内容はフィクションですが、現場で起こりそうな内容にしました。セキュリティインシデントを想定したAWSのログ取得のポイントを学んでいきましょう。
落とし穴：ログの保存方法の検討が不十分。
中堅食品メーカーのX社は、自社製品を直販する小規模な消費者向けサービスを運営している。1年ほど前、将来的なサービス拡大を見据えて、レンタルサーバーからAWSに乗り換えた。システム運用の担当は引き続き、A氏が担当することになった。
ある日、社内のセキュリティ担当から、特定の脆弱性を突く攻撃を受けていないか調査してほしいという依頼を受けた。利用しているソフトウエアに危険度の高い脆弱性が見つかったためだ。早速、A氏は調査を開始した。
「アクセスログがなくなっている！」。A氏は悲鳴を上げた。EC2インスタンス上で稼働するApache HTTP Serverのアクセスログを確認しようとしたところ、EC2インスタンスに保存されているはずの直近のログがすべて消えていたのだ。
EC2インスタンスに不正侵入した攻撃者が、内部のデータを消した可能性が急浮上したものの、これだけでは確信を持てない。ミスや誤動作の可能性もある。一定期間が経過したログはAmazon S3に出力する設定をしていたため、古いログは無事だった。だが、攻撃を受けた可能性を判断するには、やはり直近のログがないと分からない。
＊ このストーリーはフィクションです。以下も同様です。
CloudWatch AgentでEC2インスタンス外へログを常時転送。
EC2インスタンス内に侵入された場合、侵入者は攻撃の形跡を消すためにログを削除することがあります。このケースの問題点は、直近のログを安全に保管しておくための手を打っていなかったことです。AWSは、この課題の解消に役立つサービスを用意しています。それが「Amazon CloudWatch Logs（CloudWatch Logs）」と「CloudWatch Agent」です。
CloudWatch Logsは、Amazon EC2をはじめとしたAWSの各種サービスのログを収集・保存できるサービスです。一方、CloudWatch Agentは、EC2インスタンスにインストールして利用するエージェントソフトです。EC2インスタンス内の指定したログを、CloudWatch Logsに常時出力するようにできます。両者を使うと、仮にEC2インスタンス内の直近のログを消されても、CloudWatch Logs内に出力しておいたログにアクセスできます。
なお、CloudWatch Logsの利用には注意点があります。EC2インスタンスの外部でログを保管する方法としては、Amazon S3（S3）に出力（エクスポート）しておく方法もあります。これと比べると、CloudWatch Logsはログの取り込みと保管コストがやや高額です。そのため、CloudWatch Logsで保管する期限を設定しておき、それを過ぎたログはS3にエクスポートするようにするとよいでしょう。
プログラムをサーバーレスで実行する「AWS Lambda」を使うと、保管期限を過ぎたログをS3にエクスポートする作業を自動化できます。ここで詳しくは説明しませんが、興味のある人は検索して調べてみてください。
コストだけでなく、使い勝手も異なります。CloudWatch Logsに保管したログは、分析しやすいよう整理された状態を保ちます。そのため、何かあったら即座に分析したいログは、CloudWatch Logsに保管しておいたほうが便利です。一方、S3にエクスポートしたログは、分析するのに一手間かかります。アーカイブや、あとから分析するようなログに向く格納先と捉えておくといいでしょう。
外部からの攻撃を想定すると、1～2カ月程度の直近のログはCloudWatch Agentを利用して常時CloudWatch Logsに保存し、素早く分析できるようにしておくのがベターです。あとから分析するログは、社内で規定されたログの保存期間を考慮しつつS3にエクスポートして保存しておきます。
落とし穴：どのようなログを取得できているかの把握不足。
ログがないと分析できない――。困り果てたA氏は部内に一斉メールで助けを求めた。すると、前職でAWSの利用経験があるというB氏が「Application Load Balancer（ALB：負荷分散サービス）のアクセスログが残っているのではないか」と指摘した。ALBのログを調査したところ、外部からALB経由でEC2インスタンスにアクセスした形跡が残っていた。本来、あり得ないアクセスだ。
X社は攻撃を受けた可能性が高いと判断し、サービスを一時的に停止することを決めた。A氏はALBのアクセスログを過去にさかのぼって調査し、EC2インスタンスに5日前から不正侵入されていた可能性が高いと突き止めた。
どのAWSサービスでどのようなアクセスログを取得できるか把握する。
AWSでは、サービスごとにアクセスログの取得オプションが用意されています。ただし、どのようなアクセスログを取得でき、どれくらいの期間、どこに保管されるのか、きちんと確認できているでしょうか。チームで使うWikiなどの運用マニュアルに記載して情報共有しておくと、インシデント対応はより迅速になります。
今回のような脆弱性を悪用した攻撃では、HTTPリクエストに攻撃コードが仕込まれているのが一般的です。HTTPリクエストはいくつかのコンポーネントで構成され、攻撃コードの挿入箇所としてはURI、Query、Header、Bodyなどがあります。アクセスログは、サービスごとに取得している情報が異なります。どのサービスのアクセスログが、どの情報を含んでいるのかを押さえておくと、調査すべきログが素早く分かります。
| ログ名 | URI | Query | Header | Body |
|---|---|---|---|---|
| CloudFrontアクセスログ | ○ | ○ | △＊ | × |
| ALBアクセスログ | ○ | ○ | ○ | × |
| AWS WAFアクセスログ | ○ | ○ | ○ | × |
| API Gatewayアクセスログ | ○ | × | × | × |
加えて、ログがどこにどういった形式で保存されているのか記載しておけば、「どこにログがあるのか分からない」といった事態に陥ることはないでしょう。
さらにもう一つ、気をつけておきたい落とし穴があります。AWSサービスのアクセスログはデフォルト設定では無効化されていることです。ログを取得したい場合は、忘れずに「有効化」しておきましょう。上記のケースは幸いALBのログを取得していましたが、取得しない設定のままだと、この時点で“詰んで”いた可能性すらあります。
落とし穴：通信ログを取り忘れる。
ALBアクセスログに不正侵入の痕跡があったとセキュリティ担当に報告したところ、外部への不正な通信がないかを確認するよう指示があった。ネットワーク関連のログはどこにあるのか。A氏がAWSの公式ドキュメントを調べたところ、「VPC Flow Logs」という通信ログがあると分かった。だが、X社のシステムはそれを取得できていないことが、この段階で判明した。
再度B氏に相談したところ、「実際に稼働させてみて、外部への不正な通信をするかどうかを見てみてはどうか」とアドバイスをもらった。侵入の形跡があった時点のスナップショットを使ってEC2インスタンスを構築し、VPC Flow Logsを取得するように設定した隔離環境でしばらく動かすというものだ。念のため丸1日稼働させて不正な通信がないことを確認し、外部への情報送信の可能性は低いと結論付けた。
データベースへのアクセスや改ざんの形跡がなかったため、不正侵入前のスナップショットからEC2インスタンスを復旧してサービスを再開した。サービス停止以外の影響は少なかったものの、A氏は寿命が縮まる思いをした。また、「ログをきちんと取れていれば、もっと早く問題を特定できたはずだ」と深い後悔の念にかられた。
不正な通信を見つけるにはVPC Flow Logsを「有効化」。
VPC Flow Logsは、VPC（仮想プライベートクラウド）内のネットワークのログを取得するサービスです。VPC内のAWSの各種サービスは、仮想的なネットワークインターフェースを持ちます。このネットワークインターフェースごとにログを取得して、どのようなIPトラフィックが行き来したかを確認できます。
セキュリティインシデントへの対処で、攻撃の影響を判断したり、外部への通信の発生を確認したりするには、アクセスログに加えてVPC Flow Logsが必要となります。例えば、VPC Flow Logsを調べて、「セキュリティグループ＊」で許可していないIPアドレスや、「Network ACL＊」で拒否しているIPアドレスからの通信が多数発生していたと分かったら、不正アクセスの可能性があると気付くことができます。
VPC Flow Logsはデフォルト設定では無効化されています。ログを取得したい場合は、忘れずに「有効化」しておきましょう。
VPC Flow Logsが無効のままでも、このケースのように別の方法で対処できる場合もありますが、当然できない場合もあります。VPC Flow Logsはアプリケーションエンジニアだけでシステムを作ると、見逃してしまう場合があるので注意が必要です。
