パッチを当てよーっと――クラウド上でセキュリティの運用・監視を行うための基礎知識：親子の会話から学ぶクラウドセキュリティ（3）

親子の会話で出てくるような素朴な疑問点から、クラウド環境における情報セキュリティの技術を学習する連載。今回は、クラウド上でセキュリティの運用・監視を行うための基礎知識について。

[青山桃子，株式会社日立ソリューションズ]

　親子の会話で出てくるような素朴な疑問点から、クラウド環境における情報セキュリティの技術を学習する本連載「親子の会話から学ぶクラウドセキュリティ」。

　初回は、クラウドを始める前に覚えておきたいセキュリティの基礎知識、第2回はクラウド上で安全なネットワークを構築・管理するために必要な基礎知識について解説しました。今回は、クラウド上でセキュリティの運用・監視を行うための基礎知識についてです。

ログは、どこで見られるのかな？

よし、Webサービスを一通り作り終わったよ。

頑張ったわね！　ちゃんと動いているか、テストもしましょうね。ログは正常に取れているかしら？

ログは、どこで見られるのかな？

そうね、どこでどんなログが見られるかを確認しておきましょうね。クラウドでは、ベンダー側の責任範囲になっているものに関するログは、見られないかもしれないから気を付けてね。

　ログによるトレーサビリティー（いつ、どこで、何が起きたかを追跡すること）の確保は大変重要です。例えば、サイバー攻撃を受けるなどしてお客さまの情報が漏えいするというセキュリティインシデントが発生したとします。お客さまへは、何をどのように説明すればよいでしょうか？　また、会社からは原因追究や再発防止策の対応を求められることと思いますが、それらは何を元に検討すればよいのでしょうか？

　頼りになるのはログです。そもそも、自分のサービスがサイバー攻撃を受けたことや、情報が漏えいしたこと自体、ログがなければ判断するのが難しいと思います。判断できなければ、本来は自分で負う必要のない責任まで負わされかねません。つまりこのような状況において、普段からきちんとログを取得していたかどうかは、お客さまからの信頼や会社内での評価、事後対応の量や範囲に大きく影響が出るといえます。

　また、何も起こらない場合にも監査などで定められたログを提出する必要な場合があります。例えば、クレジットカード情報を扱うサービスのセキュリティ基準であるPCI DSS（Payment Card Industry Data Security Standard）では、カード会員データへの全ての個人アクセスや、管理権限を持つ個人によって行われた操作などを監査証跡として適切に記録することが要件に挙がっています。

　クラウドの場合、インフラはクラウドベンダー、設定がユーザーなどと分かれているため、自分の管理責任範囲のログしか見られない場合があります。「どんなログが見られるか」、設計の段階であらかじめ確認し、「必要なログが見られない」といった状況に陥らないようにしておきましょう。

　セキュリティに関して、注目すべきログには以下のようなものがあります。目的によって取得するログのサイズや保管期限、記録する内容を決定しましょう。

種類	概要
アクセスログ	ユーザーがサービスにアクセスした情報を記録するログ
イベントログ（システムログ）	システムに発生したイベントを記録するログ。内容はアプリケーションの起動やエラー、設定変更、ログインの成否など
クラウド基盤に関するログ	クラウド基盤の管理コンソールへのログイン、インスタンスの設定変更などの操作を記録するログ
セキュリティイベントのログ	IDS（侵入検知システム）などにおける悪意のある通信や操作の検知ログ
ネットワークトラフィックのログ	通信に関するログ。パケットキャプチャーやNetFlowなどがある

　また、ログを取得する際には時刻同期が重要です。問題が発生してログを照会する際には、複数の機器やサービスのログを突き合わせる場合が多いので、時刻がずれていると正しい状況を判断することが難しくなります。クラウドの場合、時刻同期がベンダー側の責任になっているサービスもあると思います。もし、ユーザーの責任範囲になっているOSが固有の時間設定を持っているような場合は、ベンダー側の時間と誤差がないよう注意しましょう。

　Amazon Web Services（AWS）では、イベントログやクラウド基盤に関するログを取得するサービスとして、「Amazon CloudWatch Logs」「AWS CloudTrail」「AWS Config」などが利用可能です。セキュリティイベントのログなどは、AWSのセキュリティステータスを一括表示する「AWS Security Hub」で確認可能です。また通信の取得には、「Amazon VPC（Virtual Private Cloud）」のネットワークインタフェースを通るIPトラフィックをキャプチャーする「Amazon VPCフローログ」があります。

AWS CloudTrailにおけるログの確認

あれっ、いつの間にかサービスが動かなくなっているよ？

あれっ、いつの間にかサービスが動かなくなっているよ？

あら大変。アラートを設定して、こういうときにすぐに気付くようにしておこうね。

うん。でも、なんで止まっちゃったのかな？

直前にリソース使用量が突然増えているみたいね。何があったか調べて、同じことが起こらないようにしましょうね。

　サーバの死活監視、CPUやネットワークトラフィックなどのリソース利用率の監視は、一般的にはセキュリティではなく通常のシステム運用の分野として語られることが多いと思います。しかし、リソースの監視は、セキュリティ面でも可用性や攻撃検知／追跡などの観点で重要です。通常と異なる状況を観測した場合、障害の発生以外にも、悪意のある行為が行われている可能性があります。セキュリティの観点で監視、調査をする上でも、通常のシステム運用の指標にも注意するよう心掛けましょう。

　またクラウドの環境では、リソース利用量に伴い課金されるため、課金金額を監視することも大切です。急激に課金額が増えている場合、何らかの原因でリソースのトラブルや悪用が発生している可能性があります。

　AWSではCPUなどのリソースの状態は「Amazon CloudWatch」で確認可能です。アラートの作成もできます。また、ログやセキュリティなども含め総合的なシステムの監視ができるオープンソースソフトウェア（OSS）である「Elasticsearch」の機能を提供するマネージドサービス「Amazon Elasticsearch Service」も利用可能です。

Amazon CloudWatchにおけるCPUなどのリソース状態の監視

パッチを当てよーっと

あ、使っているOSSの新しいセキュリティパッチが公開されているよ。パッチを当てよーっと。

パッチを当てるときは一時的にサービスが止まったり、再起動が必要だったりする場合があるのよ。本番環境を更新するときは注意してね。

分かったよ。

他にも、パッチを当てた後に、他のソフトウェアや環境の都合で不具合が出る可能性もあるよ。本番相当の検証環境でパッチ適用のテストを行ってから、本番環境を更新しましょうね。

　セキュリティパッチは定期的に公開されるものもあれば、予告なく公開されるものもあります。特に緊急度が高いものは予告なく公開され、なるべく早い適用を求められるので、速やかにパッチが適用できるように準備しておかなければなりません。

　パッチを適用する場合は、事前に検証するのが一般的だと思います。クラウドの環境はオンプレミスの環境に比べてインスタンスなどの複製が容易なので、本番環境を複製した検証環境を作成してパッチを検証し、問題がなければ本番環境へパッチを適用することが可能です。また設定変更などのテストも、同様に検証環境を作成して行えます。

　本番環境へのパッチ適用の際は、サーバの停止時間を設ける必要がありますが、「AWS Auto Scaling」を利用して複数のインスタンスを運用している場合などは、1インスタンスずつ順番にパッチを適用することで、サービスを継続して運用できます。

エラーが出ちゃった、元に戻したいよう

パッチを当てたらよく分からないエラーが出ちゃった、元に戻したいよう。

あらあら。バックアップを取ってあるかしら？　スナップショットでもいいわ。

スナップショットがあるよ。

よかった。過去のスナップショットに戻しましょう。

　基本的なことですが、パッチの適用やシステム更新の前には、必ずバックアップを取るようにしましょう。また、サイバー攻撃や障害が発生した場合に備えて、定期的にバックアップを取っておくことも重要です。

　バックアップは複数世代取るようにしましょう。例えば、サーバがマルウェアに感染してしまった場合に、感染したことにすぐに気付かないことがあるかもしれません。「気付いて元に戻そうと思ったときに、数時間前に定期バックアップが実行されて、直前のバックアップには感染済みのイメージが上書きされており、復旧できない」という状況になるかもしれません。バックアップを複数世代取っていれば、定期的なバックアップの間隔に応じて「少なくとも1日前のバックアップ」「少なくとも1週間前のバックアップ」を確保できます。

　クラウドの場合、インスタンスのバックアップのためにスナップショットを作成する場合が多いと思います。AWSでは、手動でスナップショットを作成可能ですが、「Amazon Data Lifecycle Manager」を利用して、スナップショットの作成、保持、削除を自動化することもできます。

　また、スナップショットは同様にクラウド上に作成されるため、スナップショット自体の管理設定にも気を付けましょう。スナップショットにはサーバと同等のデータが含まれています。設定を間違えて、誰でもアクセス可能な設定などになっていると、スナップショットを不正にコピーされ、サーバの中のデータを盗み見される可能性があります。

　バックアップだけではなく、リストアの確認も定期的に行っておきましょう。リストアは普段の運用の中では実施しないので、「もし不備があっても、それが分かるのはセキュリティインシデントなどが発生してしまった後」ということになります。「いざ戻そうとしたときに、バックアップがうまく作成されていなかった」といった問題があっては大変ですよね。

自動的にやってほしいなあ

パッチを適用したり、システムを修正したりするたびに手順がたくさんあって大変だね。自動的にやってほしいなあ。

そうね、手順がたくさんあるとヒューマンエラーの原因にもなるから、できるだけ自動化しておきましょうね。頻繁に更新するシステムならCI/CD（継続的インテグレーション／継続的デリバリー）ツールも使ってみるといいわよ。

　マネージドサービスとしてAWSやサードパーティーのベンダーに任せる部分以外の操作手順も、できるだけ自動化しておくことをお勧めします。ヒューマンエラーを防止する目的以外にも、個々の担当者に依存しない運用になるので、複数人で運用する場合や、担当者が変わった場合にスムーズに事を進めることができます。

　AWSでは、パッチ適用には「AWS Systems Manager Patch Manager」が利用可能です。

　また、システムの更新にはCI/CDのツールやサービスを用いた構築の自動化が可能です。CI/CDとは、アプリケーションの構築、テスト、デプロイといった、リリースまでの一連の流れを自動化する手法を指します。セキュリティに関するテストを一連の流れに組み込んでおくことで、安全ではないサービスが公開されるのを防ぐことができます。

　AWSでは「AWS CodePipeline」「AWS CodeBuild」「AWS CodeDeploy」などが利用可能です。OSSでも、「Jenkins」などさまざまなCI/CDツールが提供されています。

サービスを稼働する前に、できるだけ運用を自動化しておこうっと。

それがいいわ。がんばってね！」