使いやすく、安全なシステム。セキュリティ対策のポイント　　　　

まず想像されるのが、情報セキュリティは自分たちが持っているシステムや格納された情報を組織の外に漏洩しないということです。最近だと悪意のある組織がハッキングやクラッキングをしかけてデータを抜き取るケースが増えました。ですから、外部からの防御というのが大きな課題となっています。

ですが、事例でいえば内部の関係者から情報が漏洩してしまうケースが多いんですね。組織の内部を知り尽くした上でデータを抜き取られるとなると、被害としては二重に大きくなってしまうと思います。

意図的に持ち出す場合、あるいはうっかりした手順違いで漏洩してしまう場合、あらゆる場面を想定してカバーする必要があります。システム的に作り込んだり、従業員への教育を定期的に行うなど、網羅的に対策することになります。

そうですね。外側、内側という二つの視点がないと、結局は情報が流出してしまうのです。

データを破壊される、抜き取られるというのは致命的なのですが、DoS攻撃のようにサーバ自体をダウンさせられてしまうと、クラウドサービス自体が提供できなくなります。サービスのクオリティが低下して、業務フローがすべて止まってしまうということにもなりかねません。

サービスを24時間365日稼働させ続けるにはどうしたらいいかという視点も大事です。スマホやパソコンでいつでも接続できるのが当たり前の世の中ですから、インフラとしての責任、バックアッププランを考えねばなりません。

少しセキュリティ用語にはなりますが、可用性、機密性、完全性というセキュリティ要件は平常時、異常時とあらゆる状況を想定して考えています。

Mogicは、以前からセキュリティに対して然るべき運用体制を持ち、第三者から審査を受けて改善を続けています。クラウドサービスを提供しはじめてすぐにプライバシーマークを取得して、先日6回目の更新を迎えました。

そして、より一層情報の取り扱いを厳密化するということで、昨年にはISMSの認証を受けています。これらの審査はそれぞれ2年に1回、1年に1回とオフィスで見ていただいています。またセキュリティ委員会として各部門から1名ずつアサインされて、月に1回以上は話し合いを行なっています。

プライバシーマークは、取り扱う個人情報の適切な管理をしているかということです。
クラウドサービスを提供するにあたり、管理システムから利用者の情報をご登録いただきますので、そちらを適切に管理しなければならないということです。

ISMSは会社が保有している情報資産を洗い出して、ラベリングして、誰がどう取り扱うかを明文化しているものです。誰もがあらゆる情報に触れられるようになっていると、漏洩の原因になりますから、ルール化しつつできるだけシステムで管理しています。
そうした意味で、PマークとISMSを併せて取得していることが、信頼感につながるのだと考えています。

さきほどもお伝えしたとおり、プライバシーマークは2年に1回、ISMSは1年に1回更新審査があります。どんなにうまくやっていても審査員から、新しい指摘を受けます。それをセキュリティ委員会で議論しながら、最終的に監査、セキュリティ責任者に承認をもらっています。何度も更新をしてきましたから、やるほど対策が進んでいると感じています。

最初に苦労したのは、やはりプライバシーマークやISMSが持っている情報セキュリティの定義から全体の運用フローの理解ですね。過去に起きた事例から対策が網羅的に作られているんだと思いますが、専門用語もありますし、セキュリティ委員全員が理解して進むのに時間がかかりました。

ですから、最初の審査は指摘事項が多かったと記憶しています。それを社内に持ち帰って、なぜここが抜けているんだろうと話し合いました。更新の際は各部門の担当者が審査員から面談を受けるので、全員が分かっていないといけませんから。

審査員から最短での取得と言われました。

そうですね。プライバシーマークでセキュリティの運用に全員が慣れていましたし、管理体制、システム化、教育が整っていました。なので、あとはISMSの枠組みに従って入力していったということです。

ISMSに関しては、もともとクラウドのシステムで情報資産を管理していたので、書類の更新作業に手間取りませんでした。その点、プライバシーマークは依然としてドキュメント書類で運用していますので、やや手間がかかっていますね。

従来の考え方ですと、大事な情報は基本的にクラウドに上げずに、ローカルのセキュアなファイルサーバでドキュメント書類として管理する、という方式でした。ですが、最近はクラウドでもセキュアに管理することもできるようになってきているので、確かに使い分けに迷うことはありますね。

そこでどういう風に考えるかというと、基本に立ち戻ってまずは情報の重要度によってグラデーションをきちんとつけるということです。

最も漏洩を防ぎたいものは、ローカルでネットワークにつながず、物理的に施錠して、接触者を絞ればいいですね。ただそれだと利用頻度が高いと使いづらいので、次に社内のネットワーク限定で限られた人だけ閲覧できるもの。オンラインのネットワークで限られた人が確認できるものと分けていく感じです。最も重要なものは外部に配置しないことを徹底します。

もちろんeラーニングシステムをサービスとして提供していますから、お客さまがクラウドにデータを保存されることを考慮にいれなければなりません。クラウドサーバを提供している会社がセキュリティに対して然るべき対応をしているか、性悪説にたってこちらからも監視しています。

そのあたりはプライバシーマークやISMSに限らず、システム開発するときも同じ思想でやっています。管理者を絞ったり、利用者のハードルを下げたり、あとはシステムの負荷を下げることも同じです。お客さまは利便性に目がいきやすい傾向にあるので、こちらでセキュリティの視点をアドバイスするのが大切です。

まず考えるのは、情報は触れるべき人にしか開示しないということです。管理するシステムであれ、利用者が使う画面であれ、すべての情報を出すということはありません。開示すべきでない人には絶対に出ないように仕組みを作ります。開発を進めていくにあたり、レビューをもらいますが、そこはすごくしっかりとチェックされていると思います。

どのプログラムで情報漏洩が起きると最も深刻な事態になるか、リスクが最も高い場所をチームで認識合わせしています。開発をする体制、テストをする体制いずれでも情報漏洩が起きるとすればどこかと事前に話すようにしています。

あとはすべてを同じレベルで守ることはできないので、守るべきところをたくさん作らないようにしています。すべてに等しく対応するというより、守るべきところを集約してそこをしっかり守る考え方です。

家で例えると分かりやすいですね。入口がたくさんあればそれだけ侵入される可能性が上がります。侵入された後に漏洩するリスクも高まりますから。なので、入口は最小限にして死角がなく侵入者がそもそも入ろうとする気を削ぐ感じです。

人に関わる部分で情報漏洩するのは大きく3つあります。システムを使う時に誤った操作で漏洩するケースと、セキュリティの自覚がなく漏洩するケース、悪意をもって漏洩させるケースです。

誤操作で漏洩するケースは必ず防ぎたいですね。メール送信システムを例に出すと、宛先を登録し、編集するところで作業ミスをしやすい。メールは送ってしまうと取り返しがつかないので、作業者が一番緊張するところです。誤って削除したり、宛先を間違えてしまうなどのミスが起こらないようにデザイナーと連携して、ユーザビリティからも予防策を考えます。

セキュリティ意識は教育で徹底するしかないです。知らなかったでは済まされないことが多いので、入社時に自社のeラーニング教材で学習し、最低でも3ヶ月に1回はオンラインセミナーとテストを実施する。加えて、仕事をしながらセキュリティの対策を話しています。

さらにリスク管理委員会が設置されているので、担当部門以外の目線で社内の潜在リスクを1ヶ月に1度チェックしてもらっています。先に先に手を打つという感じです。悪意をもって漏洩させるケースにも何らかの兆しがあると考えていますから、事前に兆候はないかとヒアリングしているようです。

人はどうしてもミスをしてしまうので、ミスをする前提でその確率を減らし、万が一の状況が起きてもリカバーできるように考えておくことが大事かと思います。

セキュリティ、セキュリティといってしまうと過剰に不安になられるかもしれませんが、やはり大事なのでこちらから都度お話していきます。

ただ、漠然と全てをガチガチに守りたいということではないんですね。ご自身が使われるシステムにおいて、どれが一番重要でそれをどう取り扱うべきかということに解像度が上がっていくといいなと思っています。

後は人は絶対に何らかミスをしてしまいますから、それを考慮してどうアクションされるかをお互いに議論できるといいですね。リリースした後にシステムに不具合が出てきたり、使っていきながらミスしやすい場所が見つかったりします。そういう現実的な運用の流れの中で、何が最善なのかと模索していく一つのチームになれればすごく強くなれる気がしています。

絶対にこれが正解という方法はなく、プライバシーマークやISMSの認証があるから完璧なんだということもなく、不完全さを受け止めて油断することなく改善を続ける姿勢が大事だと考えています。

システムはプログラムでできていますし、クラウドサーバで展開されています。ほぼ目にみて細かく確認することができないものですから、開発を担当する会社として誠実にセキュリティを分かりやすくお伝えする義務があると思っています。場合によっては、セキュリティを優先するために仕様が増えることもあり、その場合にきちんとご納得いただけるようにしています。

やはりセキュリティもコミュニケーションが大事だと思っています。ご相談いただく際に「こういうシステムを作りたい」「こういうことをやりたい」とお聞きします。前提はやりたいことや実現したいことが中心です。

それからMogicでシステムの設計を始めるのですが、そこで細かくリスクが見えてきます。「このあたりは情報漏洩のリスクがありますね」「利便性は確かにこちらがいいけれど、すごく重要な情報だから確認画面をはさんだ方がいいですね」ということをすべてお出ししています。

その上で「リスクを取ってもやりたいから、どう最小化できるんだろうか」となる場合もあれば、「それは確かに厳しいから、違う作り方はないだろうか」と議論しています。判断していただくには大切なリスクやセキュリティの情報がないといけませんから。

さきほど出てきましたけど、全部が全部セキュリティを高めすぎると開発リソースも費用も莫大にかかります。莫大な予算で全部やりますというのは現実的ではないですから、うまくセキュリティとやりたいことのバランスをとるしかありません。

さらにいえば、開発する側がセキュリティを高めたシステムを作っても、実際に運用されるお客さまの業務フローや意識が高まっていないと穴ができてしまうんですね。お客さまとシステムを作る会社のリスク意識が揃ってはじめてトータルで守れるものだと思いますから、コミュニケーションが大事です。

自社ブランドでサービスを運用しているのもノウハウとして大きいですね。eラーニングシステムLearnOは10年以上、授業支援システムPhollyは7年ほど。自分たちが端から端まで面倒をみて育ててきたサービスがあり、直接お客さまからの問い合わせを受け続けてきました。

机上で考えたのではなく、実地の声を拾ってお客さまが気にされているポイントや潜在的なリスクの知見が溜まっているのだと思います。多くの会社とお付き合いさせていただく中で事例が集約されて知恵になっています。そういうバックグラウンドがありますから、これからもお問い合わせいただくお客さまのお力になっていきたいですね。

ありがとうございました！