クラウドとテレワーク時代、企業に二要素認証・多要素認証の利用が求められる理由

Share

二要素認証とは、IDとパスワードだけでなく、パスワードに加えてトークンや指紋など、計2つの要素を用いて本人確認を行うことです。今回の記事では、認証に用いられる3つの要素に触れながら、「多要素認証」「二段階認証」との違い、実際の使用例、アメリカ国立標準技術研究所(NIST)の認証に関するガイドラインなどを解説し、企業がこうした認証方式をどのような場合に用いるべきかを提案します。

二要素認証とは

インターネットにおける「認証」とは、たとえば、あるWebサービス等を利用しようとしているユーザが、本当にその本人であるか、その正しさを確認するプロセスや行為のことです。「二要素認証」とは、セキュリティ水準を高めるために、ふたつの要素を用いて認証を行うことです。

「KNOW」「HAVE」「ARE」、認証に用いる3要素とは

「要素」とは、認証に用いる情報等のことです。たとえば、あるWebサービスの利用時、IDとパスワードの入力が求められるのであれば、それは「IDを持つ人がこの人であるかどうかを確認するためにパスワードという要素が用いられている」ということになります。

要素には、パスワードのような「ユーザが知っていること(something you know」、部屋のカギのような「ユーザが所持しているもの(something you have」、指紋や虹彩(眼球の瞳の周辺にある膜)のような「ユーザ自身であるもの(something you are」などがあり、このうちどれかふたつの要素を用いて認証を行うことを二要素認証と呼びます。

二要素認証を行えば、従来のようなパスワードだけを用いた認証よりも、セキュリティ水準を高めることができます。

「二要素認証」と「二段階認証」「多要素認証」の違い

過去に日本国内で普及していた認証方法に「二段階認証」があります。これは、パスワード入力の後に「秘密の質問」などを設けて、ユーザが知っていることを用いてもう一回認証を行い、セキュリティを高めようとするものです。

「多要素認証」とは、「ユーザが知っていること(something you know)」「ユーザが所持しているもの(something you have)」「ユーザ自身であるもの(something you are)」のうち、ふたつ以上の要素を用いて認証を行うことで、二要素認証は多要素認証に含まれます。

なお、多要素認証は英語では「MFA(Multi-Factor Authentication)」と表記され、2つの要素を用いる場合に「Two-Factor Authentication」という呼称が使われることがあります。

よくある「秘密の質問」は、セキュリティ的にはどうなのか

余談になりますが、「秘密の質問」を用いるタイプの二段階認証は、2020年現在、ユーザの認証手段に常時使われることは望ましくない、というのが多くの専門家の認識となっており、多要素認証が利用できない場合の非常代替手段として、またはアカウントの回復に用いる認証の一部として、限定的に用いられることが望ましいとされています。

もし秘密の質問を使う場合には、「(何年たっても思い出せる程度に)記憶できる」「(何年間も答えが変わらず)一貫性がある」「(どんなユーザでも)回答可能である」「(攻撃者が答えを知ることがない程度に)機密性が高い」「(どのユーザでもわかるように)明確である」という5つの条件を満たすことが望まれます(*)

基準となるNISTのガイドライン

アメリカ国立標準技術研究所(NIST)が公開しているガイドライン「SP 800-63」(最新版は2017年公開の第三版「SP 800-63-3」)は、オンラインで行われる認証に関して最も参照されるドキュメントのひとつです。

同書は、NISTが考える「電子認証はこうあるべき」を記載したもので、「SP 800-63A」「SP 800-63B」「SP 800-63C」から構成されています。

SP 800-63Aでは認証やIDの管理全般について記述し、SP 800-63Bはトークン等の認証器の仕様として「AAL1」「AAL2」「AAL3」の三種類を定め、SP 800-63Cではフェデレーション認証について記述しています。

日本の経済産業省の規格も「SP 800-63-3」を参照して作られています。

LINE、Google、Facebook、Slack ~ 二要素認証・多要素認証を使用した具体例

すでに、LINEやGoogle、Facebook、LinkedIn、Slackなどの大手ITサービスでは、二要素認証・多要素認証が利用されています。スマートフォンやメールアドレス宛にパスコードを送る、「Authenticator」と呼ばれる認証用アプリにパスコードなどを表示させるなど、方法もさまざまです。

以前「ブルートフォース攻撃」に関する記事で解説したとおり、サイバー攻撃の激化・高度化にともなって、パスワードだけで認証する時代はもう終わりを迎えています。今後、二要素認証・多要素認証は上記に挙げた大規模なサービスにとどまらず、企業内でも積極的に活用されていくことでしょう。では、どんな場面でこれを用いればいいのでしょうか。

「企業が二要素認証・多要素認証を使うべき」2つのシナリオとは

SQAT.jpでは、「セキュリティのレベルが異なる領域間でのアクセスや通信」に対して、二要素認証・多要素認証を使うことをおすすめしています。

具体的な例を挙げると、「クラウドサービスを利用するために、社外のクラウドサービスのアカウントに社内からアクセスするとき」、そして、「テレワーク等の実施のために、社外からイントラネットなど社内にアクセスするとき」のふたつです。

特に、社外からイントラネットなど社内にアクセスするときは、トークンを使った多要素認証を用いたVPN接続をおすすめします。

なお、SNSやメールサービスなどのSaaSで、ユーザ本人のアクセスであることを確認する必要性が高いサービスなどでも、多要素認証が用いられることが多いといえます。社内からこうしたサービスにアクセスしている場合、当該サービスが多要素認証を適用しているか、適用できるような設定になっているかも確認してみてはどうでしょう。

クラウドサービス利用時はアイデンティティアクセス管理等、認証まわりに注意

SQAT.jpを運営する株式会社ブロードバンドセキュリティでは、主要クラウド(IaaS)を対象としたセキュリティ診断サービスも提供していますが、診断の結果リスクを指摘される事項の大半が、認証に関わる問題です。クラウドサービスを、つい「オンプレミス環境の延長」あるいは「オンプレミス環境と同じ」と考えてしまうことで、誤った設定がなされてしまうことがあるようです。詳細は、「診断結果にみるクラウドセキュリティの今」で詳しく解説していますので、ぜひご覧ください。

まとめ

  • 二要素認証とは、「KNOW」「HAVE」「ARE」という3つの認証要素の中の2つを用いて認証を行うことです。
  • 二要素認証は多要素認証に含まれます。
  • 二要素認証・多要素認証を行うことでセキュリティ強度を高めることができます。LINE、Google、Facebookなど多くのサービスでこの認証方式が使われています。
  • NISTが公開したガイドライン「SP 800-63-3」は認証に関して世界で最も参照されるドキュメントのひとつです。
  • セキュリティのレベルが異なる領域間でのアクセスや通信には、二要素認証・多要素認証を使うことをおすすめします。
  • クラウドサービスを利用する場合は、認証関係の設定ミスに注意しましょう。

Security Report TOPに戻る
TOP-更新情報に戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

クロスサイトリクエストフォージェリ(CSRF)はサイバー攻撃の「名脇役」?
脆弱性診断におけるCSRFの検出頻度と対策

Share

今回は、XSSのような「大物の脆弱性」と比較すると、一見地味に見えてしまう「CSRF」の意外な危険性について解説します。

CSRFが脆弱性診断の現場で検出される頻度や、見つかった際に行うべき対応、そもそもCSRFの脆弱性をアプリケーションに作り込まないための予防策、また、脆弱性を放置するとGoogle Chromeなどの主要ブラウザでWebサイトを閲覧できなくなることなどを説明します。

CSRFとは

Webアプリケーションの脆弱性のひとつであるCSRFは、「Cross Site Request Forgery(クロスサイトリクエストフォージェリ)」の略称です。読み方は「シーサーフ」です。英語で「Cross」は「X」と表記することがあるため、CSRFを「XSRF」と表記することもあります。

「クロスサイト」は「Webサイトをまたぐ」という意味で、「リクエスト」はユーザがWebアプリケーションなどに処理を要求すること、「フォージェリ」には「偽造品」などの意味があります。CSRFは、攻撃者が罠として用意した偽造サイトを用いて、ユーザが意図していないリクエストを強制的に行わせるサイバー攻撃です。

CSRFとXSSの違い

クロスサイトリクエストフォージェリと似た名前の脆弱性に「クロスサイトスクリプティング(XSS:Cross Site Scripting)」があります。どちらもサイトを横断(Cross Site)してサイバー攻撃が行われる点が共通していますが、それ以外は何ら同じところはない別物で、発見される頻度や攻撃による影響、対策方法は異なります。

脆弱性診断の現場でCSRFはどのぐらい発見されるか

あなたがいまご覧になっているサイト「SQAT.jp」を運営する株式会社ブロードバンドセキュリティでは、日々、さまざまなお客様のシステムに対して脆弱性診断を行っています。

ブロードバンドセキュリティが2020年上半期に総数4,596のシステムに対して行った脆弱性診断の結果、CSRFを含む「セッション管理関連の脆弱性」は17%のシステムで検出され、その中にCSRFは12%含まれていました。つまりCSRFの脆弱性が存在したシステムは17%×12%、全体の約2%になります。ここで2%という数字をどうとらえたらよいのか、このあと、CSRFの攻撃例やリスクを紹介しながら考えていきます。

CSRFによる攻撃と被害例

CSRFの脆弱性を悪用した攻撃事例としては、掲示板等に本人が全く意図していない書き込みをさせた例(「遠隔操作ウイルス事件」や「はまちちゃん事件」が有名)があります。

もしCSRFが脆弱性診断で見つかったら、すぐに対応が必要な場合もあります。特に、個人情報の登録や変更などに関わるログイン後のページで発見された場合は、すぐに修正を行わなければなりません。

意図しない掲示板の書き込み以外にも、CSRFの脆弱性を悪用すれば、たとえば「サイトAにログインして会員登録を行っているつもりが、実際には攻撃者が罠として用意したサイトBにログインしており、そこで個人情報を抜き取られる」ような攻撃が行われる危険性もあります。もしそうなれば、サイト運営者としての責任が厳しく問われることは間違いありません。

対策を怠ると他サイトへの遷移ができなくなる可能性も

また、主要なWebブラウザは、XSSやCSRFなどからの保護のために、脆弱性のあるWebサイトをブラウザに表示させない仕様を整えつつあります。たとえばGoogle Chromeは、Chrome 80以降、サイトを越えてCookie情報をやり取りするためのSameSite属性に対して制限を加え、CSRFを防御可能な設定値のみを許容する方向へと段階的に進んでいます*1 。CSRFを防御可能な設定値については他の主要ブラウザも同様の方向に進んでおり、Webアプリケーション開発においてCSRF対策は(他の対策とともに)取らないわけにはいかないものの一つとなりつつあります。

セキュリティ企業が見るCSRFのリスクとは

なお、わたしたちセキュリティ診断サービス会社にとってCSRFとは、一定頻度で検出されるものの、CSRF単体ではそれほどリスクは大きくない脆弱性です。事実、CSRFだけを使った攻撃事例はあまり多くないのです。

CSRFで注意すべきは、他のサイバー攻撃手法と組み合わされることでリスクや被害が大きくなることです。

たとえば「セッションフィクセーション」と呼ばれるセッションIDを強制・固定化する攻撃と、CSRFの脆弱性を悪用した攻撃を組み合わせることで、「セッションハイジャック」と呼ばれるサイバー攻撃が成立すれば、セッションの乗っ取りが行われ、オンラインバンキングでの不正送金などにつながる可能性があります。

CSRFのリスクは低い? 高い?

CSRFだけを考えてしまうとリスクはそれほど高くないため、対応は後回しにされがちです。しかし実際のサイバー攻撃はそう単純ではなく、いくつもの方法が複合されて行われます。「見つかったらすぐに対応が必要な脆弱性のひとつ」とわたしたちが考える理由がそこにあります。

CSRFは、単体では攻撃者にとってそれほど使い勝手の良い脆弱性ではありません。しかし、CSRFはいわば、自身では主役は張れないものの、サイバー攻撃の主役を引き立てるために機能する、名脇役のような脆弱性と言えるかもしれません。

CSRFの対策とトークンによる保護

CSRFの脆弱性を悪用した攻撃で最も警戒すべきはログインしたユーザをターゲットとした攻撃になります。この場合、ログインしたユーザからの正しいリクエストであることを証明するために、「トークン」と呼ばれる推測困難な文字列を使って確認を行うことや再度の認証を行うこと*2などで攻撃を防ぐことができます。

事実、PHP、Java、ASP.NET等の開発言語で提供されている、Webアプリケーションフレームワーク(Laravel、Spring等)は、CSRFの脆弱性を悪用した攻撃を防ぐために、ユニークなトークンを発行する仕組みを持つようになっています。しかし、それでもなおCSRFの脆弱性が見つかることがあるのです。これはどうしてでしょう。

なぜCSRF攻撃対策のトークンは発行されないのか

開発フレームワークがトークンを発行する機能を持っているのにWebアプリケーションでCSRFの脆弱性が発見される理由は、単純そのもので「そもそもトークンを発行するための1行がかかれていない」*3から、ということが多いのです。「機能があるから大丈夫だろう」という思い込みが思わぬリスクを招きます。

前半で、ブロードバンドセキュリティが行った脆弱性診断の結果、約2%でCSRFの脆弱性が検出されたとお伝えしましたが、リスクを知り、適切な対策を確実に実装することで、この数字をもっと少なくすることができるでしょう。

まとめ

  • CSRFとは、「シーサーフ」と呼ばれる、攻撃者が罠として用意したサイトを用いて、ユーザが意図しないリクエストを強制的に行わせることを可能にする脆弱性です。
  • CSRFとXSSは、どちらもサイトを横断してサイバー攻撃を行う点だけは共通していますが、発見頻度やリスク、対策方法は異なります。
  • もし、個人情報の登録などに関わるログイン後のページでCSRFの脆弱性が発見された場合、すぐに修正する必要があります。
  • Google Chromeほかの主要ブラウザでは近年、CSRFの対策に有効とされる制限を開始しています。対応しない場合にはWebサイトがブラウザに表示されなくなる可能性もあります。
  • CSRFは他のさまざまなサイバー攻撃と組み合わされて利用されることが多いので、たとえCSRF単体のリスクが低くても確実に対策を行うことが重要です。

Security Report TOPに戻る
TOP-更新情報に戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像