Menu
  1. HOME
  2. ユニリタマガジン
  3. 2016年UNIRITAマガジン
  4. 【2016年8-9月合併号】 デジタルトランスフォーメーションに 必要な技術とは? Vol. 2 ~セキュリティも「まことに日に新たなり」~

【2016年8-9月合併号】 デジタルトランスフォーメーションに 必要な技術とは? Vol. 2 ~セキュリティも「まことに日に新たなり」~

前回のコラム「 デジタルトランスフォーメーションに必要な技術とは? Vol. 1 ~クラウドサービスはまことに日に新たなり~」では、クラウドサービスは常に改善を繰り返す開発方法が必要であるという話をしました。今回は、おそらく皆さまが最も心配している「セキュリティ」の話です。

セキュリティを脅かす脅威といっても、幾つかの手口があります。「サイバー攻撃」、「標的型攻撃」、「リスト型攻撃」などです。「サイバー攻撃」とは、ネットワークで到達可能なサーバを攻撃して、システムダウンや改ざんを目的とする攻撃を言います。DoS攻撃などはこれにあたります。「標的型攻撃」は、特定の会社の内部情報を盗むために、コンピュータウイルスをメールなどで送り込み、ウイルスを使って内部情報を盗み出す方法です。最近では、比較的セキュリティの弱いと思われる子会社にウイルスを送り込み、さらにその子会社から親会社にメールを送り込むことで、グループ間のメールを装って安心させてからウイルスを送り込むといった手の込んだものがある様です。

今回テーマとしたいのは、「リスト型攻撃」です。ID/パスワードのコンビネーションを盗むことで、さまざまなシステムを乗っ取るやり方です。特に、情報システムではシステム毎に個別のセキュリティの仕組みを持つことが多いため、ID/パスワードが分散されてしまいます。この分散にセキュリティのリスクが内在しているため、気を付けなければなりません。

社内のセキュリティポリシー

皆さんは 普段どれ だけのシステムを利用しているでしょうか?メールや業務システム、ワークフローなど数えるときりがありませんが、すぐには思いつかない仕組みもあります。例えば、年に数回のリハーサルと広域災害が発生した場合にのみ利用される安否確認のシステムです。

皆さんの会社では、ISMSやPマークなどの個人情報についての認定を受けていると思います。その認定取得のために、システムのセキュリティとして、「パスワードは8桁で英数字と特殊文字を使ったコンビネーションにすること」や「パスワードは3 ヶ月に1回変更すること」などのルールが決められているかと思います。では、安否確認のシステムもそのポリシーに従っているでしょうか? 私の知る限り、安否確認のパスワードを3 ヶ月に1回変更している会社はごく僅かです。また、クラウドサービスの事業者を利用しているため、パスワードの桁数なども自社のポリシーに従っているのでは無く、事業者のセキュリティポリシーに依存していることが多くなります。そのため、パスワードの桁数や変更に関するポリシーに従うか従わないかは個人のセキュリティに対する感受性に頼っているのが現状です。

この様な話に対して、「安否確認の仕組みは破られてもたいした影響は無い」と判断されるシステム担当者も中にはいらっしゃるかと思います。しかし、リスト型攻撃の恐ろしさは「そこ」にあります。

リスト型攻撃はなぜ問題なのか?

皆さんが使っているシステムのほとんどは、IDとしてメールアドレスまたは社員番号を利用していると思います。また、パスワードもおそらく同じ物を使いまわしていることでしょう。ある調査会社によると、9割の人は同じパスワードを使いまわしていると言われています。それでは、パスワードの使い回しを禁止するのか?もし禁止すると、

  1. ノートにメモをする
  2. パスワードの下何桁かをあるルールに従って変更する
  3. 思い出しやすいパスワードを採用する

などの対応をします。メモすることは特に危険ですのでやめましょう。手帳が盗まれたり、落としたりした場合に、面倒なことになります。財布を落として、クレジットカード会社に電話をかけまくった経験のある人は、容易に想像することができるでしょう。2)のパスワードの下何桁かを変えるルールですが、自分も思い出せないとダメなので、そのルールはある意味ロジカルなものになってしまいます。それが本当に安全かどうかは疑問です。

さて、先ほどの安否確認のシステムに戻りますが、確かに安否確認のシステムは破られてもたいした影響はないかもしれません。しかし、その部分のセキュリティ強度が弱いために、社員番号・メールアドレス・パスワードが全てハッキングされてしまったらどうなりますか? 社員全員のID/パスワードのリストが闇取引されてしまうかもしれません。そして、そのIDとパスワードは、他の非常に重要なシステムのIDパスワードのコンビネーションでもあります。IDがメールアドレスであれば、その会社のメールサーバにアクセスを試みて、リストの上から順番にログインを試みます。先ほどの統計でいくと、1000人の従業員のリストが漏れると、900名のメールアカウントが乗っ取られることになります。

意外と怖いリスト型攻撃

リスト型攻撃はコンピュータプログラムでパスワードを組み立ててログインするのとは異なり、通常のWebサイトから人間のオペレーションでログインされます。コンピュータプログラムにより、ハッキングされる場合は、ある特徴が浮かび上がります。例えば、「同一IPから1秒間に数千回以上のアクセスが発生する」や「昨日はロサンゼルスからログインしていたのに、今日は東京からログインしている」などです。この場合はハッキングが試みられていると気づくことができます。現在では人工知能(AI)が普及してきているため、AIにその判断を任せることができるかもしれません。しかし、通常のオペレーションでログインされると、ハッキング行為に気づきません。つまり、知らない間にメールを読まれていて、長い間その状況に気づかない場合があります。人手でやっているからたいした被害は無いであろうと思われやすいリスト型攻撃は、他の方法よりもむしろ危険であることが多いのです。

社内のセキュリティポリシー

リスト型攻撃はID/パスワードのコンビネーションが盗まれることで、あたかも本人がログインしているかの様にシステムを利用します。これは、社内システムを利用する際、認識するサーバが多いこと(分散)が問題です。この問題は、認証を1箇所にすることで避けることができます。メールシステムや安否確認システム、受発注システムも1箇所で認証して利用することができれば、その1箇所の認証を強化することで問題のほとんどは解決します。IDとパスワードのコンビネーションをあちこちに分散してしまうと、1番セキュリティの弱いところが破られて、その影響が多くのシステムに及びます。お分かりになりましたでしょうか?これが「安否確認ぐらいはいいじゃないか?」が危険だということです。

リスト型攻撃の対策2: 認証サーバのセキュリティを高める

認証サーバを1箇所にすると、シングルポイントオブフェイラーが発生するのでは?と言う課題がでてきます。シングルポイントオブフェイラーとは、1箇所の障害で、多くの仕組みに影響を及ぼすことをいいます。「認証サーバがダウンすると、すべてのシステムが使えなくなる 」や「認証サーバが破られるとすべてのシステムが利用されてしまう」などの問題です。もちろんそのリスクは否めませんが、逆に1箇所のセキュリティを高めることで、すべてのシステムが保証されます。認証サーバに何か問題がありそうなアクセスが来れば、止めてしまえば影響を及ぼしません。認証サーバにアクセスできる端末は社内の端末しかアクセスできない(グローバルIPで制限するなど)ようにすれば、それ以外の端末からはログインすらできないため、システムを乗っ取られることはありません。

最近では2段階認証の仕組みを利用しているところが大変多くなりました。例えば、ある端末からログインを試みると、その端末は登録されていないため、スマートフォンの電話番号にSMSで6桁の数字を送ります。この数字は10秒とか30秒とかで切れるワンタイムのPINコードであるため、その場ですぐに入力しなければ無効になります。SMSは自分の携帯やスマホなどで利用できますので、携帯やスマホが盗まれない限りは安全です。携帯やスマホが盗まれた場合は通常気がつくので、管理者に話してアカウントを一時的に利用できないようにしてもらえば、誰かにアカウントを乗っ取られることはありません。この端末は一度認証されると、次回からはこの処理を行わなくてもいいので、利用上はそんなに不便になることもありません。普段利用する端末は数台ですので、その数台さえPINコードで認証をしておけば、全く問題なく利用することができます。

このようにして、1度認証サーバを1つにしてしまえば、その認証サーバのセキュリティを向上する手段はたくさんあります。2段階認証だけではなく、生体認証を使ったりすることも可能です。

お客様に安心してもらえるシステムの構築

デジタルビジネスにおいては、お客様とのやりとりにシステムが必要になることが多くなるでしょう。この場合、お客様の認証を安全に進めることはお客様サービス向上につながります。もちろん、個人情報保護の観点でも重要です。認証の強度が高いかどうかは、その企業のブランド力にもなります。一度大きな問題を起こしたことがある企業は容易に信頼を取り戻すことができません。したがって、セキュリティは一度構築すればそれで終わりではなく、継続的に向上させる必要があります。前回のコラムでもご紹介した、「まことに日に新たなり」が必要となります。

リスト型攻撃の対策に効く! infoScoopのセキュリティ関連ソリューション

セキュリティと一言でいっても単一の製品で全てを守れるものではありません。例えば、シングルサインオンの仕組みを利用しても、それは認証を1箇所にまとめることだけを意味しており、それぞれのシステムでの権限の管理やそのシステムでのアクセス許可を得るための認可についても検討する必要があります。権限管理においては、特に人事異動や退職に伴うセキュリティについて悩まれているお客様も多いかと思います。そんな時は、「infoScoop」のID管理を使って、分散されたシステムの組織や権限の情報を更新することができます。

クラウドを利用する場合、業界標準の認証プロトコルであるSAML、OpenID Connectや認可プロトコルであるOAuthを利用することでシングルサインオンを容易に実現することができますが、クラウドでも、標準プロトコルをサポートしていない事業者が多々見受けられます。この場合は、「infoScoop」のリバースプロキシによる代行ログインや、代行ログイン機能をもったポータル製品を使うことで、利用者に不便をかけずにセキュリティを確保することが可能です。

 「infoScoop」のセキュリティソリューションは、ポータル、シングルサインオン(SAML /代行ログイン)、ID管理をトータルで提供できることが特徴です。

担当者紹介

執行役員 プロダクト事業本部 Be.Cloudグループ長 
戌亥 稔

クラウド事業を担当している野球とゴルフ好きの2 児の父親です。ゴルフのスコアはあまり良くなりませんが、最近飛距離が伸びました。iPhone は2008 年の3G 発売以降、ずっと使っているガジェット好きの技術者です。

製品・サービス

情報活用の側面からワークスタイルの変革を支援する infoScoop

 

infoScoopは、「情報洪水からの脱却」 「情報へのスピーディなアクセス」を目的として開発した企業向け情報ポータル(EIP)です。
最新のinfoScoop Cloud Enterprise V4では、スマートデバイスにおける機能性と利便性をさらに高め、エンタープライズレベルの運用、管理を想定したセキュリティ機能の強化を図り、いつでもどこでも安全に必要な情報へ素早くアクセスできます。

 

会社情報に関するお問い合わせ

製品やIR以外の当社に関するお問い合わせ、本HPに関するお問い合わせなど、総合お問い合わせフォームより受け付けています。

お問い合わせフォーム