不正ログインを食い止めろ！ OpenAMで認証強化：OSSによるアイデンティティ管理（2）（1/2 ページ）
多発するパスワードリスト攻撃による不正ログインに対しては、リスクベース認証やワンタイムパスワード認証を含む多要素認証が効果的です。今回はオープンソースのアクセス管理ソフトウェアであるOpenAMの概要と、OpenAMが提供するリスクベース認証（アダプティブリスク認証、デバイスプリント認証）、ワンタイムパスワード認証（OATH／YubiKey認証）について解説します。
不正ログインに対して今できること
2013年に入ってから多発しているパスワードの使い回しを狙った不正アクセス（不正ログイン）は、半年近く経った今も継続して発生しています。このような状況を受け、「パスワードを使った認証は限界」といった声も聞かれるようになっていますが、パスワードを使わない新しい認証方式を今すぐ全てのシステムに導入する、というのは現実的ではありません。
できるだけユーザーの利便性を損なうことなく、現在利用しているシステムの認証をよりセキュアにすることが、サービス提供者やシステム管理者には求められています。認証時のセキュリティを強化するために今できることとして、次のような対策が挙げられます。
認証を1カ所に集約する
まずすべきことは、防御するポイント（認証の経路）を1カ所に集約することです。各システムがそれぞれ認証をユーザーに要求する場合、攻撃者が攻撃の対象とするポイントはそれだけ多くなり、パスワードが漏えいする可能性も増します。それらのどれか1つのシステムからパスワードが漏えいした場合、そのシステムに対してだけでなく、他のシステムに対しても不正アクセスの危険性が高まります。
また各システムごとに異なる認証方式やパスワードポリシーを採用している場合、ユーザーはパスワードの管理が困難になり、結果的にセキュリティリスクを増加させてしまいます。複数のシステムの認証ポイントを1カ所に集約し、シングルサインオン（SSO）できるように連携することで、統一したパスワードとパスワードポリシーを使用できるようになります。
多要素認証を導入する
次に、1カ所に集約した認証を多要素認証で強化します。多要素認証とは、IDとパスワードの組み合わせだけでなく、複数の情報を利用した認証方式のことをいいます。IDとパスワードのみを使った認証の場合、これらの情報が流出すると簡単に不正アクセスを許してしまうことになります。しかし多要素認証を導入していれば、IDとパスワードで認証が成功したとしても、次の認証で不正ログインを防ぐことができます。
例えば、GoogleやFacebookの多要素認証では、IDとパスワードの認証の成功後に、携帯端末に送信されたワンタイムパスワード（以下、OTP）による追加の認証が求められます。OTPとは、認証のために1回しか使えない「使い捨てパスワード」のことをいいます。
多要素認証で認証のステップが増えるとセキュリティは強化されますが、その分、利便性が下がります。そこで有効なのが、リスクベース認証です。リスクベース認証は、ログインしようとするユーザーの情報を分析し、普段と異なる環境からのアクセスと判断した場合に、本人であることを確認するために追加の認証やログインの拒否を行います。
例えば、普段は業務時間中に東京からしかアクセスしないユーザーが、ある日突然、夜中に海外からアクセスしてきた場合、本人以外の第三者が不正にアクセスを試みている可能性が高いと考えて、追加の認証を要求します。これにより第三者のなりすましによる不正利用を防ぐことができます。
不正アクセス発生後の迅速な対応への準備
認証を1カ所に集約し、多要素認証を導入することで、不正アクセスのリスクを大幅に減らすことができます。しかし、これらの対策をとっても、100％安全な認証を実現することはできません。認証が成功する方法がある以上、絶対的な安全性を保証することはできないのです。
重要なのは、不正アクセスを監視する仕組みを設けることと、不正アクセス発覚後の迅速な対応のための準備をすることです。例えば次のような対策が考えられます。
- 監査ログを監視し、不正アクセスの可能性を検知したら、システム管理者にレポートする。
- ユーザーがログインした後の画面のヘッダー部分に最終ログイン日時を表示したり、ログイン履歴の検索を行えるようにする。これにより、ユーザー自身に不正ログインを気付かせる。
- パスワードのハッシュアルゴリズムを変更できるようにする。これにより、不正アクセス発覚後に全ユーザーのログインを一時的に不可能にし、パスワードリセットを促す。
- 監査ログを詳細に記録しておき、被害状況を正確に把握できるようにする。
OpenAMで何ができるか
こうした不正アクセスへの対策において有効な手段の1つが、前回の記事にて紹介した「OpenAM」の導入です。まず、OpenAMがどのような製品で、何を実現できるのかを簡単に説明します。
OpenAMとは
OpenAMは、オープンソースのアクセス管理ソフトウェアです。米Sun Microsystemsが開発していた「OpenSSO」の後継製品です。複数のシステムへのSSO、認証の強化、アクセス制御、フェデレーション（クラウドサービスへのSSO）などの機能を実装しています。
| 主な仕様 | 詳細 |
|---|---|
| 最新版 | Release 10.1.0-Xpress / 2012年12月 |
| 実装言語 | メインはJava（CやC++なども含む） |
| 対応OS | クロスプラットフォーム |
| 対応言語 | 英語、フランス語、ドイツ語、スペイン語、日本語、韓国語、中国語 |
| サポート | ForgeRock社によるサブスクリプション、日本国内でもいくつかの企業が有償サポートを提供 |
| 機能 | アイデンティティおよびアクセス管理 |
| ライセンス | CDDL |
| 公式サイト | http://www.forgerock.com/openam.html |
OpenAMにより、複数のアプリケーションの認証を1カ所に集約して、認証を強化することができます。また詳細な監査ログを記録しているため、不正アクセスがあった場合でも被害の状況を正確に把握できます。
OpenAMが提供するセキュアな認証方式
OpenAMは、20種類以上の認証モジュールから必要なものを選択し、組み合わせた多要素認証を実現できます。認証モジュールには、IDとパスワードを使った一般的な認証だけでなく、Windowsドメインのアカウントで認証する「Windows Desktop SSO認証」やFacebookなどのOAuth 2.0プロバイダで認証を行う「OAuth 2.0クライアント認証」などがあります。さらに、独自の認証モジュールを開発し、組み込むこともできます。
このような認証の組み合わせを「認証連鎖」といいます。図2は認証連鎖の設定例です。
認証連鎖内の各認証モジュールには「条件」が設定でき、認証の成否に応じてその次の認証モジュールの実行有無と最終的な認証の成否が決まります。上の設定例では、社内の端末からアクセスした場合（Windowsドメインにログインした場合）はそのまま認証成功となりますが（十分条件）、その他の端末やスマートフォンからアクセスした場合はIDとパスワードによる認証を要求することになります（必須条件）。条件を設定して認証モジュールを組み合わせることで、このような柔軟な制御ができます。
次に、OpenAMが提供する認証モジュールのうち、不正アクセスの対策に有効なものをいくつか紹介します。
アダプティブリスク認証
アダプティブリスク認証は、OpenAM 10.0.0から追加されたリスクベース認証の1つです。ログインしようとするユーザーが本人ではないリスクを評価し、必要に応じて追加の認証を要求します。ユーザーが本人であるかどうかは、ログイン時の地理的位置、最終ログインからの経過時間や認証失敗回数、IPアドレスの履歴などで判断します。
アダプティブリスク認証でリスクを評価できる情報の一覧を以下に示します。
| チェックの方法 | 概要 |
|---|---|
| 認証失敗チェック | ユーザーが過去に認証失敗をしているかをチェックします。 |
| IPレンジチェック | クライアントのIPアドレスが、指定した範囲内にあるかをチェックします。 |
| IP履歴チェック | クライアントのIPアドレスが、過去のログイン履歴の中に存在するかをチェックします。 |
| 既知のCookie値チェック | クライアントのリクエストに既知のCookieが存在し、正しい値を持っているかをチェックします。 |
| 最終ログインからの経過時間チェック | ユーザーのログインが、最後にログインした時刻から指定した経過時間内であるかをチェックします。 |
| プロファイルのリスク属性チェック | ログインしようとするユーザーのLDAPエントリに、指定した属性と値が含まれているかをチェックします。 |
| デバイス登録Cookieチェック | クライアントのリクエストに指定した名前のCookieが含まれているかをチェックします。 |
| 位置情報国コードチェック | 許可されていない場所からのアクセスであるかをチェックします。場所の判断には、位置情報データベースを使用します。 |
| リクエストヘッダーチェック | クライアントのリクエストが指定されたヘッダーおよび値を含んでいるかをチェックします。 |
これらのチェックは複数組み合わせて設定することもできます。それぞれに設定したスコアの合計値が、リスクしきい値に到達しなければ認証成功となります。例えば、以下のように設定したとしましょう。
- 認証失敗チェックのスコア = 1
- 位置情報国コードチェックのスコア = 2
- リクエストヘッダーチェック = 3
- リスクしきい値 = 4
認証失敗チェックと位置情報国コードチェックのみが不正であっても、しきい値に達しないため認証成功となりますが、認証失敗チェックとリクエストヘッダーチェックが不正であった場合は、しきい値を超えるため認証失敗となります。
Copyright © ITmedia, Inc. All Rights Reserved.