第6回は「運用における情報セキュリティ対応」について考えてみたいと思います。
　今回は、CSIRT（Computer Security Incident Response Team）ではなく、あくまでシステム運用の一貫として行うセキュリティ対応にフォーカスを絞ります。CSIRTについては、また別の機会にお伝えできればと考えています。

目次

セキュリティとして検討しなければならない運用項目

運用の手順および責任

マルウェアからの保護

バックアップ

ログ取得

運用ソフトウェアの管理

技術的脆弱性管理

セキュリティとして検討しなければならない運用項目

　セキュリティ対策として検討しなければならない運用項目については、NISCの「重要インフラにおける情報セキュリティ確保に係る安全基準等策定指針（第5版）」の「運用時のセキュリティ管理」に記載されている内容をもとに、少し具体的に考えてみたいと思います。

・重要インフラにおける情報セキュリティ確保に係る安全基準等策定指針（第5版）

https://www.nisc.go.jp/active/infra/pdf/shishin5.pdf

上記資料に記載されている内容を開発構築と運用に分類すると以下になります。

　新たにサービスを導入する際に全社の運用ルールとして、これらの方針が決まっていれば迅速なサービス導入が可能となります。逆に決まっていないと、サービスごとにセキュリティ対策を検討しなければならなくなるのでかなり非効率です。まず、運用で検討する内容を中心に、各項目を解説していきましょう。

運用の手順および責任

　セキュリティを担保するためには、日々の運用の中でもセキュリティを意識しておく必要があります。そのために検討するのは以下の2項目となります。

■セキュリティ基準を満たした運用手順書を準備する
　手順通りに正しい作業をしていても、セキュリティ基準を満たしていない手順を実施したら、無意識に重要情報を危険にさらしてしまう可能性があります。手順通りに重要データをメールに添付して社外へ送付してしまったり、手順通りに許可されていないクラウドストレージへアップロードしてしまうかもしれません。そのようなことを減らすためにも、社内のセキュリティポリシーと運用手順書の突合せは重要となります。

■変更管理プロセスを定め実施する
　変更作業を行うと、意図せずセキュリティに悪影響を与えてしまう場合があります。特にネットワークに関わる作業や監視の変更は、予期せぬ外部との通信を可能にしてしまったり、必要だったセキュリティアラートを止めてしまったりする可能性があります。そのようなことが起こらないために、特定の作業については変更プロセスの承認前にセキュリティチェックの観点を含める必要があります。

マルウェアからの保護

　マルウェアからの保護としては、感染時の対応と外部からのデータ持ち込み、メール等の検知に対する対策などが検討されます。

■マルウェア感染時のフローをまとめる
　サーバーのマルウェア対策ソフトやIDS/IPS（不正侵入検知システム/不正侵入防止システム）などで、セキュリティインシデントを発見した場合にどうするかを事前に決めておきましょう。サービスごとに決めておかなければならない内容は以下となります。

・発見時の初動対応
・エスカレーション先
・復旧方針
・痕跡確認の手順

　特に復旧方針と痕跡確認の手順はサービスが持つコンポーネントによって違ってくるので整理が必要です。

■外部持ち込みPCやデバイスのマルウェアチェック
　特に重要なシステムの場合、業務委託先や保守ベンダーなどが持ち込むPCやデバイスなどがマルウェアに感染していないかをチェックする必要があります。
　その際は専用の検疫ネットワークを作り、持ち込み時に端末のマルウェアのチェックをする仕組みなどを構築して対応しましょう。

バックアップ

　セキュリティインシデントの復旧として、バックアップデータからのリストアが実施されます。基本的には障害対応や作業ミスなどで取得している対応と同じです。
　重要システムでは、長期間マルウェアに感染した状態からの復旧も視野に入れたバックアップ方針を検討する必要があります。

■定期的なバックアップリカバリー訓練を実施する
　本番稼働後はなかなか実施が難しいかと思いますが、検証環境などでバックアップリカバリーの訓練を実施しておくと運用者の心理的な負担が軽減されます。セキュリティインシデント発生時という状況下で、ほとんど実施したことのないリカバリー作業を実施することは、緊張によりミスを起こしてしまう可能性があります。そのような状況でもリカバリー作業に慣れていれば、緊張は軽減されます。有事に備えて、運用項目として定期的に訓練を実施することをお勧めします。

ログ取得

　ログの取得はインシデントのトレーサビリティ（追跡可能性）の確保のために重要です。いざという時に何が起こったのかを追跡するためのログを取得しておく必要があります。

　■イベントログや運用担当者の作業ログを記録する
　情報流出などのセキュリティインシデントが発覚するのは半年後や1年後の可能性もあります。サーバーなどのイベントログ取得に関してはリアルタイムで確認する短期保管の障害対応用と、それを定期的に圧縮して長期保管しておく監査用ログの2つが必要となります。これらは開発構築時に検討しておきましょう。
　それとは別に運用者の作業ログも確保しておく必要があります。これは端末側で録画やクライアント管理ソフトで操作ログを取得しておくパターンと、サービス側でユーザー操作を取得しておくパターンがあります。

監査ログを取得しておくことによる効果としては以下のようなものがあります。

・監査ログを取得していることを公表することで、作業者の不正行為に対するけん制になる
・ 作業者の不正行為を発見できる
・ セキュリティインシデントが作業者のミスなのか、サービス側の不具合なのか切り分けができる

　ログはいざという時に運用者の無実を証明してくれるものでもあります。もしミスをしていたとしても、ログを取得していればミスの内容を正確に把握することができ、迅速な復旧が可能となります。

運用ソフトウェアの管理

　ここでいう運用ソフトウェアとは、サービスを構成しているソフトウェアや製品になります。ネットワーク機器やサーバー、ミドルウェア、クラウドサービスなどを適切に管理しなければ脅威から重要情報を守ることはできません。

■運用ソフトウェアの個々の設定について可能な限り把握・理解し、安全性の確保に努める
　サービスのアーキテクチャ（設計思想）から実際の設定値まで、可能であるならばすべて把握しているのが理想です。JVN（Japan Vulnerability Notes）などで新たな脆弱性関連情報が発表された場合に、自分の運用しているサービスに影響があるかを把握するためには、サービスの設定を理解している必要があります。
　ただ、実際にすべてを把握しようと思うとかなり難しいのが実情です。管理しているシステムの把握については、継続的にメンバー教育を行っていくしかありません。逆に言えば、計画的な教育によって確実に伸ばしていけるスキルでもあります。エンジニアキャリアとして必ず必要になる部分なので、まずは自分の運用しているサービスの構成要素を把握するところから、テクニカルスキルを計画的に伸ばしていきましょう。

■運用ソフトウェアはサポート対象バージョンへの更新を計画的に実施する
　ソフトウェアや製品にはEOSL（End Of Service Life：サービス終了）があります。継続してサポートを受けるためには、定期的なバージョンアップに追随していく必要があります。バージョンアップでは新たな機能が追加されるため、その機能を利用するかどうか、利用する場合は新たなセキュリティ対策が必要かどうかなど、多岐にわたる検討をしなければなりません。まずは通常の運用としてバージョンアップを対応するのか、それともプロジェクトとしてベンダーに依頼するのかを決めておきましょう。関連システムとの兼ね合いでバージョンアップできず塩漬けとなるソフトウェアもあります。その際は補完的な措置、つまりベンダーと個別でサポート契約を結んだり、代替となるサービスの導入を検討したりする必要があります。

技術的脆弱性管理

　脆弱性情報は日々収集して穴をふさいでいかなければなりません。地味な仕事ですが、こうした日々の小さな努力がセキュリティインシデントから企業を守っているとも言えます。それに、実際にセキュリティインシデントが発生した際のコストと対応にかかる時間を考えれば、脆弱性管理の作業は微々たるものともいえます。

■技術的脆弱性に関する情報を収集し影響の有無を確認する
　運用しているサービスを構成するソフトウェアや製品の脆弱性情報を日々収集する必要があります。JVNであればメール通知、クラウドサービスなどは公式SNS、ブログなどをフォローして情報を収集できる仕組みを作っておくとよいでしょう。メール通知やSNSやブログなどは、最新情報が公開されたらLCDPでビジネスチャットツールなどの1ヵ所に情報を集約するのもよいかと思います。

■重要システムでは定期的な脆弱性スキャンを実施する
　脆弱性スキャンとは、ファイアウォール、ルータ、サーバー、アプリケーションなどサービスが関わる要素に対して、ツールなどで定型的な疑似攻撃を広範囲に行う診断になります。脆弱性スキャンの対応は専門の業者に依頼することがほとんどかと思います。
　定期周期に関しては、業界ごとのガイドラインに従うことになります。どのガイドラインでも、重要システムでは最低でも年に1回、もしくは重要な変更があった場合に診断するように求められています。

■パッチ適用の影響確認のため、その作業方針と作業内容をあらかじめ確立する
パッチ適用に関しては、前後作業も含めて以下のことを決めておく必要があります。

　これらの検討項目は定期パッチでも緊急パッチでも基本的には変わりません。定期と緊急との違いは、実施フローや判断などのリードタイムが短くなるだけです。緊急パッチを適用できないような塩漬けのシステムで脆弱性を許容する場合は、その脆弱性をついた攻撃が行われていないかを定期的にログから確認するなど、補完的な措置が必要になります。

　半年にわたって連載してきた「システム運用改善 虎の巻」も今回で終了です。このコラムは、「運用改善の教科書」からの抜粋がほとんどです。運用改善にご興味を持たれた方は、是非「運用改善の教科書」もお手に取っていただければ幸いです。

図の出典：『運用改善の教科書　～クラウド時代にも困らない、変化に迅速に対応するためのシステム運用ノウハウ』