第4回 運用上のセキュリティ保持に関するチェックポイント

IT・IT製品TOP > Key Conductors > 齊藤 愼仁(アイレット株式会社) > 第4回 運用上のセキュリティ保持に関するチェックポイント
この記事をtweetする このエントリーをはてなブックマークに追加

IT現場の道先案内人 Key Conductors

第4回 運用上のセキュリティ保持に関するチェックポイント

データセンター 2016/03/31

 連載の最終回にあたる今回は、昨今、特に注目度が高い「CSIRT(シーサート/Computer Security Incident Response Team)」について、当社が構築・運用している例を紹介します。

 システムへの攻撃は、当たり前ですが「弱点を狙う」のが常套手口です。OSやアプリケーションに既知の脆弱性があれば、そこがピンポイントで狙われる危険性が高いです。こうした攻撃に対処するためには、脆弱性情報や攻撃予兆情報に常に注意を払い、最新の情報を迅速に入手して社内で共有・分析し、必要な対応をできるだけ短時間で実施することが求められます。事前に対応方針や対応手順を策定しておくことも必要です。このような作業の中心的な役割を果たすのがCSIRTです。

 情報セキュリティ委員会等はすでに組織化されていても、インシデント・レスポンスの迅速化やインシデント発生予防の視点では業務が必ずしも整理されてこなかった企業も多いのではないでしょうか。とはいえ最近の脅威傾向を考えると、CSIRT機能の見直しと整備がすべての企業にとって急務となっていることは間違いありません。第4回目ではcloudpackが公開しているホワイトペーパー「Security White Paper」にある「脆弱性情報に対する対応」について紹介します。

脆弱性情報に対する対応を行う体制

 まず最初に第2回で触れた「責任共有モデル」を思い出して下さい。お客様システムのアプリケーションやデータはお客様自身の責任であり、AWSが提供するインフラ部分はAWSの責任になります。一方、AWSインフラ上にcloudpackが導入したソフトウェア等は、cloudpackの責任になります。そこで当社では、それらソフトウェアに関する脆弱性情報を常に収集し、お客様環境のセキュリティに影響する情報が見つかれば、直ちに影響調査を行うとともに、お客様に対して連絡を行い、回答があり次第、迅速に対応する体制を敷いています。下図はそのワークフローです。

脆弱性情報に対する対応ワークフロー

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

脆弱性情報に対する対応ワークフロー

 このワークフローは当社のマネージドサービスの例なので、一般のITユーザ企業の場合とは異なります。もし参考にされるならば、CSIRTの基本的な役割はどんな企業でも変わりはありませんので、図の右側の列(ユーザ様)を「業務部門」あるいは「経営層」などに置き換えるとうまく応用できるかもしれません。

CSIRTの役割とイベントハンドリングのプロセス

 一般論として、少し解説をするとCSIRTは主に次のような業務を担います。

【脆弱性対応】
脆弱性情報収集、脅威分析、パッチの適用や設定変更など。

【インシデントハンドリング】
インシデントの発生を検知(外部機関からの通報による検知ケースが多い)したら、対処方針を決め、解決にあたる。

【事象分析】
インシデントを分析、原因特定や再発防止の策を練る。

【普及啓発】
従業員に教育・啓発活動を行う。

【注意喚起】
被害拡大防止のため、インシデントの原因や発生事実などを通知するなど、関係先に注意喚起を行う。

 特に重要なのがインシデントハンドリングです。これにはあらかじめ決められたポリシーと手順がないと、いざという時に適切な動きができません。インシデントが発生しても慌てずに行動できるように、明文化されたポリシーや手順書を用意しておく必要があります。

 図1をもう一度ご覧下さい。cloudpackでは、JPCERTコーディネーションセンター(JPCERT/CC)が公表している脆弱性情報や、cloudpackスタッフがさまざまな情報源から集めてくる脆弱性情報、お客様からの脆弱性情報へのお問い合わせなどから、常に最新の脆弱性情報を共有し、cloudpack内で組織されているcloudpack-CSIRTが影響調査及びその緊急度の判定を行います。脆弱性対応が必要と判定した場合は、影響するお客様に速やかに連絡を行います。
 
 ここで最優先すべきは、お客様の「事業継続」です。したがって、お客様から「対応の許可を得たあと」に脆弱性対応を行うことになります。脆弱性対応のためにソフトウェアにパッチを適用する際、お客様の業務システムにどんな影響が出るのか把握しきれないケースでは、パッチを適用するかしないかの判断をお客様にお願いしています。緊急度が高い脆弱性でパッチを適用するという判断が下れば、対応方法を提示・ご確認いただいた上で対応を進め、完了までのプロセスを管理し、お客様に報告します。パッチを適用しないという判断になった場合でも、その証跡(エビデンス)を残す作業をお願いしています。
 
 要するに事前に定義されたこと以外はお客様の承認がなければ行わないポリシーなので、人によっては「なんて気が利かないんだ!」と思うかもしれませんが、最新のパッチを当ててアプリに影響が発生し、サービスがダウンしてしまう可能性を考えると元も子もないので、むしろ気の利いた詳細なポリシーを策定しておくことで、多くのケースで迅速な対応につながるとも言えます。ITユーザ企業であれば、事業部門や経営層との連携を強めることで、詳細な対応ポリシーを策定できるのではないでしょうか。
 
 度々、報道されているDDoS攻撃については、AWS側で緩和できる機能を備えているサービスもあります。それでも大手のお客様の中には、リージョン単位でAWSが機能しなくなることを想定して、AWS CloudFormationなどのサービスを駆使して他のリージョンでサービスが継続できるBCP対策を講じているケースもあります。

 今回は、cloudpack-CSIRTによる脆弱性対応のあらましを紹介しました。前回までの記事と合わせ、ホワイトペーパーの主要部分を紹介できたと思います。興味をお持ちになられた方は、是非ホワイトペーパーをダウンロードしてご一読下さい。
 
 セキュリティ対策では「どこまでやればよいのか?」という問いに答えはありません。しかし、今回の記事に示したようにセキュリティに関する取り組みに透明性を持たせ、評価や検証を可能な形にすることが、関係者相互の理解につながるということと、納得できるセキュリティ体制構築に役立つと当社は信じています。セキュリティポリシーの策定や運用に悩んでいる方にとって、本記事が少しでも参考になれば幸いです。

クラウドを納得して活用するベストプラクティス:セキュリティホワイトペーパー公開中!

会員限定で「読者からのコメント」が読み書きできます! 「読者からのコメント」は会員限定の機能。会員登録を行い、ログインすると読者からのコメントが読み書きできるようになります。

会員登録(無料)・ログイン

Myリストへ 印刷用ページへ

この記事をtweetする このエントリーをはてなブックマークに追加


この寄稿記事に掲載している情報は、掲載日時点での情報となります。内容は変更となる場合がございますのでご了承下さい。また、「Key Conductors」の寄稿記事及び当該記事に寄せられたコメントについては、執筆者及びコメント投稿者の責任のもと掲載されているものであり、当社が、内容の最新性、真実性、合法性、安全性、適切性、有用性等を保証するものではありません。


30008612


IT・IT製品TOP > Key Conductors > 齊藤 愼仁(アイレット株式会社) > 第4回 運用上のセキュリティ保持に関するチェックポイント

このページの先頭へ

キーマンズネットとは
AWSインテグレーターcloudpack所属(アイレット株式会社)。x86系プロセッサを中心としたサーバーの企画・設計やHPCハードウェアのプリセールスなどに参画した経験を持つ。現在は社内インフラのセクションリーダーを担当。情報セキュリティ管理責任者、個人情報管理責任者、PCI DSS管理責任者を兼務する。

ページトップへ