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

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

ご利用のEメールアドレスが、何らかの形のフィッシングやデータ侵害に利用されていないかどうかを知りたい場合は、Troy Hunt の Have I Been Pwned （外部サイト・英語）データベースが優れています。このサービスからは分かることは、私たちが同じパスワードを再利用することが侵害につながることと、個人リソースと企業リソースの両方で同様にパスワードの再利用されていることの２点で、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 をご覧ください。