「ISMS規格をわかりやすく解読する」シリーズの21回目は、「A.14システムの取得、保守及び開発」の後半部分について見ていきたいと思います。

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

A.14.2開発及びサポートプロセスにおけるセキュリティ

この節では、システム開発の業務時に取るべき管理策が具体的に書かれています。そのため、システム開発をしない会社がISMSを取得する場合は、ここに書かれている管理策を「適用除外」とし、管理策の検討対象から外してしまうことがよくあります。

しかし、システム開発を行っている会社にとっては、非常に重要な管理策になります。

それと同時に、ここに書かれている管理策は、普段から開発業務に従事している人にとっては「あたりまえ」の事が多いです。

開発者にとっては、こんなことまで定めなければいけないの？と思う部分が多々あるかもしれませんが、自社の開発方針を振り返り、開発の基準をつくるいい機会だと前向きに捉えて、取り組んでいただければと思います。

ところで、チームで開発を行う場合には、「開発方針」や「コーディング規約」といった、開発の指針となる文書やマニュアルを定めることが多いと思います。

このA.14.2をざっくり言ってしまうと、「そのような、開発の指標となる文書やマニュアルを定めましょう」ということが、具体例とともに書かれています。

各具体例すべてを解説していると、かなりのボリュームになってしまうため、今回は一部をピックアップしてお話します。

A.14.2.2

A.14.2.2では、「システムの変更管理手順」を定めましょう、といった事が書かれています。

「システムの変更」と聞くと、とても幅広い概念ですが、例えとして具体例をあげるならば、サーバの設定を変更したり、新しくサーバを追加したり取り除いたり、といった事が挙げられます。

更に拡大解釈すれば、サービス内の新しい機能のリリースや、コードのデプロイなども、「システムの変更」に該当するかもしれません。

そういった、起こりうる様々な「変更」に対して、それらを「管理する手順」をつくりましょう、ということが書かれています。

ところで「管理する手順」とは何かというと、例えばデプロイ時のログをとる、サーバの設定を変更する前は事前に承認者の承認を得る、重大な変更を行う場合は、万が一を考慮して、現状に復帰する方法を考えておく、サーバのコマンドは記録しておく、などが挙げられます。

「これをしなければいけない！」といった内容は一切書かれていませんので、自社の組織文化にあった、変更管理の手順を定めるのが良いでしょう。

A.14.2.3

A.14.2.3では、「OSが変更された時のアプリケーションの影響について、レビューをしましょう」ということが書かれています。わかりやすく言うならば、サーバのOSを変更する場合の手順を定めておきましょうということです。

具体的には、テスト環境や予備のサーバなどで動作確認を行ってから、運用環境に上げるなどといった方法が一般的です。

また、OSだけでなく、利用しているライブラリやミドルウェアを変更する場合や、プログラミング言語のバージョンを上げたりする場合にも、同様のレビューを行うように定めておけば、セキュリティレベルはさらに向上すると思います。

少人数で開発を行っていると、各エンジニアが、ある環境に勝手にライブラリを導入したり、アップデートしたりといったことが発生する可能性もあります。そうならないように、適切なルールを定めることが大切です。

A.14.2.5

A.14.2.5では、「セキュリティに配慮したシステムを構築すべき」と書かれています。こちらもざっくりした内容ですが、シンプルに言い換えてしまえば、システムのアーキテクチャ設計をセキュアにしましょうということです。

代表的な例としては、webサーバやAPサーバとDBサーバは分離する、DBサーバはレプリケーションする、サーバやネットワークを冗長化する、ファイアウォールを設置する、などが挙げられます。

サービスごとにシステムの設計内容は違うと思いますが、どんなサービスでも、基本的な原理原則としては変わらない部分があると思います。

自社が提供するサービスとして、「ここだけは譲れない！」「この部分だけはしっかり設計してほしい！」という部分を洗い出し、まとめておくと良いでしょう。

A.14.2.6

A.14.2.6では、開発環境について書かれています。通常の開発業務では、開発環境、テスト環境、本番環境など、複数の環境を使い分けることが一般的だと思います。それらの環境について、ルールを定めましょうということが書かれています。

「環境のルール」と言われてもややピンとこないかもしれませんが、例えば、「本番環境にアクセスできるのは限られた人のみにする」とか、「テスト環境と本番環境のパスワードは分ける」などといったことです。

A.14.3試験データ

ISMSの規格では、ご丁寧に試験データの取り扱いについてまで書かれています。といっても、詳細に扱い方が書かれているわけではなく、「試験データは適切に保護し、取り扱いましょう」と、これまたざっくりと書いてあります。

絶対にやってはいけないことは、個人情報や重要情報(パスワードや外部に公開されていない情報)が含まれた本番データを持ってきて、それを試験データにそのまま利用するということです。どうしても本番データを扱いたい場合は、マスキングを行い、個人情報や重要情報が推測できない形にデータを改変してから行うのがおすすめです。

よくありがちなのが、確かに試験データはマスキング処理したものを利用しているが、マスキング前のデータがそのままPCのゴミ箱などに残ってしまっていることです。マスキング処理が終わり次第、個人情報や重要情報を含むデータはすぐに削除するよう、ルールを定め、実践していくことが大切です。