MFAでアイデンティティハックを阻止する

「もしかして騙された?」これは以前、自分自身に問いかけたことがある質問でしょう。フィッシングや盗まれた資格情報は、依然として侵害の主要な脅威手段の 1 つであり、ハッカーが巧妙になるにつれて、従業員や消費者はデジタルアプリケーションにアクセスするために使用する資格情報についてよりスマートになる必要があります。一方で、企業は、従業員が毎日使用するアプリケーションへのアクセスを効果的に保護するために、フィッシング・データ対策などに焦点を当てる必要があります。

ご利用のEメールアドレスが、何らかの形のフィッシングやデータ侵害に利用されているかを知りたい場合、Troy Hunt の Have I Been Pwned データベースが優れています。このサービスからはわかることは、私たちが同じパスワードを再利用することが侵害につながること、また個人リソースと企業リソースの両方で同様にパスワードの再利用されていることもわかり、大変よく利用されています。弱いパスワードが広く使われているため、多要素認証 (MFA) 等セキュリティ強化のツールを実装することは大変重要です。

全体像をつかむため、次のシナリオを考えてみましょう。ある従業員が LinkedIn のアカウントを持っており、彼の雇用主は Office 365 や Salesforce のようなエンタープライズアプリケーションを使用しているとします。そしてハッカーが、この従業員が働く組織は、「AtkoCorp」だと特定することができた、とします。この後ハッカーは、このユーザーの受信箱にログインし、代わりにEメールを送信したり、組織が直面する他のセキュリティ脅威にドアを開けたりします。Office 365 の場合の脅威をシミュレーションビデオで示したように、ユーザーが 1 つのパスワードを他の場所でも再利用している場合でも、MFA を実装すれば、この種のアカウントの乗っ取りは防止が可能です。

MFA の必要性を示す

まず、みなさんに、Have I Beed Pwned データベースをご紹介しましょう。これ利用すると「LinkedIn はかつてデータ侵害に巻き込まれたこと」が特定できます。次に、ハッカーが LinkedIn を介し、AtkoCorp 従業員のブルース・ウェインに標的を絞った、というシナリオを考えていきます。ハッカーはデータを侵害してブルースの LinkedIn ユーザー名とパスワードへのアクセスを手に入れ、ブルースのアカウントを使い、彼が AtkoCorp のセキュリティチームに所属していることを確認した、とします。

ここから、アカウントの乗っ取りプロセスを開始するのは難しくありません。まず、ハッカーはブルースの LinkedIn のパスワードを使用してSalesforce アカウントにログインしようとし、失敗します。次にハッカーは、ユーザーがEメールアドレスを使いログインする Office 365 に移ります。多くの企業が、従業員の名前と苗字を含めたEメールアドレスを使用するので、これを当てるのはそう難しくありません。ハッカーは、いくつかのEメールとパスワードの組み合わせを試行します。MFAを導入していない場合は、ハッカーは即座にログインできてしまい、攻撃の次の段階を実行してしまいます。

本当の被害が始まるのはここからです。AtkoCorpには高度なパスワードポリシーはないので、ハッカーはブルースになりすまし、彼のアカウントのパスワード変更リクエストを簡単に実行し、Eメールにリセットリンクを受け取ります。ハッカーはセキュリティチームのメンバーであるブルースになりすまし、同僚たちに特権情報へのアクセスを依頼します。このシナリオでは、なりすましのブルースは AtkoCorp のアプリケーションサーバーの1つにログインすることができてしまい、「ハッカーはブルースのユーザー名とパスワードをすでに所有しているため、サーバーの IP アドレスさえわかればいい」と、事は大変シンプルに進んでいくのです。

MFA がログイン体験をいかに安全にするか

MFAのような強力なセキュリティ対策はデータ・セキュリティ侵害といった攻撃を防止できます。今日、Office 365は、よりセキュアなログインを提供するために、Federation や MFA のようなセキュリティ対策をサポートしています。当社の広範な統合ネットワークの一部として、Office 365 はユーザーを安全に保つために Okta と協力しています。

先ほどのシナリオに話を戻しましょう。AtkoCorp は Okta のシングルサインオン (SSO) と MFA を実装することにしました。そのため、ブルースが Office 365 にログインすると、彼は AtkoCorp の Okta ダッシュボードにリダイレクトされ、ここで彼はユーザー名とパスワードを入力します。この時ブルースは、ログインを完了するため、追加の要素を提供しなければなりません。

Okta のモバイル認証アプリ「Okta Verify」は、組織が利用できる対策の一例で、これでエンドユーザーに、ログイン試行を簡単に確認することができます。このアプリには、「ユーザーが接続しようとしている場所、IP、ブラウザタイプ」があらかじめ設定され、これに基づき「このログインリクエストに関連するリスクを判断」し、ユーザーを確認する必要がある場合にはプッシュ通知を送信します。Okta Verify のプッシュリクエストを受け入れ、彼の ID を偽って確認する手段は存在しないので、このシナリオでは、ハッカーはブルースのアカウントを使用できません。

Office 365 のセキュリティの保護は、SSO と MFA の実装だけではなく、コンテキストに基づく適応認証も含む「IDとアクセス管理 (IAM) ソリューション」を選択することがとても重要です。例えば、ハッカーが Tor ブラウザ上でブルースのアカウントにログインしようすると、Tor からのアクセスをブロックする AtkoCorp のポリシーが適用され、その結果ハッカーはアクセスを拒否されます。

コンテキストに基づいたアクセス決定を利用すると、エンドユーザーエクスペリエンスを損なうことなく、最高のセキュリティが実現します。AtkoCorp が営業していない国からのアクセスを拒否するポリシーを設定すれば、ハッカーが AtkoCorp のオフィスがない場所からブルースのアカウントにログインしようとしても、ブロックされます。

究極的には、侵害されるパスワードがない場合も、エンドユーザーをアカウント乗っ取りから保護します。ブルースが AtkoCorp のオフィスがある場所からログインする場合、パスワードを入力するボックスは表示されません。ブルースがユーザー名を入力するとすぐに次のページにリダイレクトされ、そこで Okta Verify プロンプトを承認します。バックエンドでは、Okta は「デバイス、ネットワーク、場所のコンテキスト」を評価し、セキュアなパスワードレス体験を提供します。

この Office 365へのログインのシミュレーションから、「ハッカーがいかに簡単にアカウントへのアクセスを入手できるか」、また「企業のセキュリティはMFA を実装すれば、もはやこの問題に頭を悩ませることがなくなること」がわかります。真に堅牢なセキュリティのためには適応型ソリューションを導入することが最適であり、そうすることで、セキュリティと利便性のバランスをとることが可能です。これにより、何を許可し、拒否するかをインテリジェントに決定を下し、MFAをプロンプトしたり、パスワードレスのログイン体験を提供します。

Okta が Office 365 以外全てエンタープライズアプリケーションを保護する方法について、より詳しくは、Okta Adaptive Multi-Factor Authentication をご覧ください。