null

「ISMS規格をわかりやすく解読する」シリーズの24回目は、「A.17事業継続マネジメントにおける情報セキュリティの側面」について見ていきたいと思います。

※今回利用する「ISMS規格」とは、JIS Q 27001:2014を指します。
※用語の定義は、JIS Q 27000:2019によります。

A.17.1 情報セキュリティ継続

組織は常に、地震をはじめとした自然災害や火事、最近ではコロナ禍など、事業継続が困難な状況に陥る可能性をはらんでいます。

仮に上記のような状況に陥った場合にいかに事業継続ができるようにし、提供サービスの欠落を最小限に抑えるのか、といったことを管理する考え方として、「事業継続マネジメント」というものがあります。

この章での目的は、その事業継続マネジメントにおいて、情報セキュリティの面からもリスクを考えて対応できるようにしておきましょうということです。

A.17.1.1 情報セキュリティ継続の計画

まずはじめにすべきことは、事業継続が困難な状況に陥ったときに、情報セキュリティの管理(いわゆる機密性・完全性・可用性の維持)や情報セキュリティマネジメント(情報セキュリティのための取り組み)を継続させるための要求されるニーズや期待を決めることです。

具体的には、「社内ネットワークを〇時間以内に復旧させる」「提供サービスを〇時間以内に復旧させる」などが考えられます。また、提供するサービスの停止原因がAWSなどインフラサービス側でのトラブルであることが想定される場合などには、「AWS復旧後、〇時間以内に復旧させる」といった形の計画を立てることも想定されます。
ここで立てた計画は、絶対に守らないといけないというわけではありません。事業を継続させるためにはこれくらいの目標を掲げて、その計画を達成できるように準備をすることが重要になります。

A.17.1.2 情報セキュリティ継続の実施

続いてすべきことは、前項で定めた計画を達成するための準備をして、実際に困難な状況に陥ったときにはあらかじめ準備したことに基づいて実行するということです。

具体的には、ネットワークや提供サービスを復旧させるための手順書を準備しておくことや、それぞれの状況に応じて必要な人員に対する緊急連絡網を用意しておく、通常時に利用している連絡手段が取れなくなった場合の連絡方法を用意しておくなどといったことが考えられます。

A.17.1.3 情報セキュリティ継続の検証、レビュー及び評価

最後にすべきことは、実際に準備した方法で困難な状況に対処できるか、はじめに定めた要求レベルに応えられるものであるかということをテスト、評価するということです。

いくら準備していても、ぶっつけ本番では慌ててうまくいかないことや、実際に困難な状況が発生してみると、準備している方法では要求レベルに応えることができない・復旧できないといったことがあり得ます。そうした準備不足をなるべく減らすためのテストということです。学校などでよく行われている避難訓練のようなイメージです。

イメージだけでなく、実は、避難訓練もここで挙げられる準備のためのテストとして有効な方法です。一見、情報セキュリティの側面とはつながっていないように見えますが、従業者という人的資源は情報セキュリティ継続にとっては重要な資源のひとつであり、その人的資源を適切に保護するという意味では、立派な情報セキュリティ継続の試験です。

その他の方法としては、「緊急連絡網や導入している安否確認システムを実施してみる」「実際にファイルサーバが止まった際の復旧を手順に則って行ってみる」といった方法や、実際にシステムを止めることが難しい場合は、あらかじめ作成したマニュアルをもとに、試験環境で対応をシミュレーションしてみるといったことも有効です。最近では、コロナ禍に合わせて、リモートワークを実施して不具合が発生しないかといったことをテストとして実施するケースも多くみられます。

A.17.1では上記のように、事業継続が困難になった場合の情報セキュリティ面からの要求レベルを想定して、そのための準備をして、準備した方法が有効かテストするといった事業継続のための小さなPDCAを回すということが記載されています。

A.17.2 冗長性

提供するシステムや、自社のネットワークなど情報処理を行う設備や施設に障害が発生した場合にも、場合によって事業の継続は難しくなることがあります。

この章の目的は、上記のような情報処理を行う設備や施設を、利用が許可されている人が利用したいときに利用できるようにしておきましょうことです。つまり可用性を維持するということです。そのための方法として、冗長性という考え方が出てきます。

A.17.2.1 情報処理施設の可用性

具体的に行うこととしては、システムやネットワークは、同様の予備システムを用意しておき、できるだけ早く予備システムに移行し運用再開できるようにしておくといったことが挙げられます。ただし、同じシステムなどを複数用意することはコストのかかることであるため、止まったら大きな損失や障害につながる可能性のあるシステム(特に金融システム、インフラシステムなど)を決めて、そこに対してのみ重点的に行っていくといった取捨選択も大切になってきます。

その他には、冗長性が担保された外部サービス(クラウドストレージサービスなど)を利用することや、サービス提供において複数のリージョンを利用するといったことも考えられます。

ISMS規格をわかりやすく解読する【A.17 事業継続マネジメントにおける情報セキュリティの側面】

null

「ISMS規格をわかりやすく解読する」シリーズの24回目は、「A.17事業継続マネジメントにおける情報セキュリティの側面」について見ていきたいと思います。

※今回利用する「ISMS規格」とは、JIS Q 27001:2014を指します。
※用語の定義は、JIS Q 27000:2019によります。

A.17.1 情報セキュリティ継続

組織は常に、地震をはじめとした自然災害や火事、最近ではコロナ禍など、事業継続が困難な状況に陥る可能性をはらんでいます。

仮に上記のような状況に陥った場合にいかに事業継続ができるようにし、提供サービスの欠落を最小限に抑えるのか、といったことを管理する考え方として、「事業継続マネジメント」というものがあります。

この章での目的は、その事業継続マネジメントにおいて、情報セキュリティの面からもリスクを考えて対応できるようにしておきましょうということです。

A.17.1.1 情報セキュリティ継続の計画

まずはじめにすべきことは、事業継続が困難な状況に陥ったときに、情報セキュリティの管理(いわゆる機密性・完全性・可用性の維持)や情報セキュリティマネジメント(情報セキュリティのための取り組み)を継続させるための要求されるニーズや期待を決めることです。

具体的には、「社内ネットワークを〇時間以内に復旧させる」「提供サービスを〇時間以内に復旧させる」などが考えられます。また、提供するサービスの停止原因がAWSなどインフラサービス側でのトラブルであることが想定される場合などには、「AWS復旧後、〇時間以内に復旧させる」といった形の計画を立てることも想定されます。
ここで立てた計画は、絶対に守らないといけないというわけではありません。事業を継続させるためにはこれくらいの目標を掲げて、その計画を達成できるように準備をすることが重要になります。

A.17.1.2 情報セキュリティ継続の実施

続いてすべきことは、前項で定めた計画を達成するための準備をして、実際に困難な状況に陥ったときにはあらかじめ準備したことに基づいて実行するということです。

具体的には、ネットワークや提供サービスを復旧させるための手順書を準備しておくことや、それぞれの状況に応じて必要な人員に対する緊急連絡網を用意しておく、通常時に利用している連絡手段が取れなくなった場合の連絡方法を用意しておくなどといったことが考えられます。

A.17.1.3 情報セキュリティ継続の検証、レビュー及び評価

最後にすべきことは、実際に準備した方法で困難な状況に対処できるか、はじめに定めた要求レベルに応えられるものであるかということをテスト、評価するということです。

いくら準備していても、ぶっつけ本番では慌ててうまくいかないことや、実際に困難な状況が発生してみると、準備している方法では要求レベルに応えることができない・復旧できないといったことがあり得ます。そうした準備不足をなるべく減らすためのテストということです。学校などでよく行われている避難訓練のようなイメージです。

イメージだけでなく、実は、避難訓練もここで挙げられる準備のためのテストとして有効な方法です。一見、情報セキュリティの側面とはつながっていないように見えますが、従業者という人的資源は情報セキュリティ継続にとっては重要な資源のひとつであり、その人的資源を適切に保護するという意味では、立派な情報セキュリティ継続の試験です。

その他の方法としては、「緊急連絡網や導入している安否確認システムを実施してみる」「実際にファイルサーバが止まった際の復旧を手順に則って行ってみる」といった方法や、実際にシステムを止めることが難しい場合は、あらかじめ作成したマニュアルをもとに、試験環境で対応をシミュレーションしてみるといったことも有効です。最近では、コロナ禍に合わせて、リモートワークを実施して不具合が発生しないかといったことをテストとして実施するケースも多くみられます。

A.17.1では上記のように、事業継続が困難になった場合の情報セキュリティ面からの要求レベルを想定して、そのための準備をして、準備した方法が有効かテストするといった事業継続のための小さなPDCAを回すということが記載されています。

A.17.2 冗長性

提供するシステムや、自社のネットワークなど情報処理を行う設備や施設に障害が発生した場合にも、場合によって事業の継続は難しくなることがあります。

この章の目的は、上記のような情報処理を行う設備や施設を、利用が許可されている人が利用したいときに利用できるようにしておきましょうことです。つまり可用性を維持するということです。そのための方法として、冗長性という考え方が出てきます。

A.17.2.1 情報処理施設の可用性

具体的に行うこととしては、システムやネットワークは、同様の予備システムを用意しておき、できるだけ早く予備システムに移行し運用再開できるようにしておくといったことが挙げられます。ただし、同じシステムなどを複数用意することはコストのかかることであるため、止まったら大きな損失や障害につながる可能性のあるシステム(特に金融システム、インフラシステムなど)を決めて、そこに対してのみ重点的に行っていくといった取捨選択も大切になってきます。

その他には、冗長性が担保された外部サービス(クラウドストレージサービスなど)を利用することや、サービス提供において複数のリージョンを利用するといったことも考えられます。

Author: 石濱 雄基
  • はてなブックマークに追加
  • ツイートする
  • facebookでシェアする
  • LINEでシェアする