第3回 IDaaSの実装をAzure ADで理解する（後編）：企業のID管理／シングルサインオンの新しい選択肢「IDaaS」の活用（1/2 ページ）
オンプレミスでの実装と比べて、IDaaSのセキュリティは大丈夫なのか？ 引き続きAzure ADを例に、IDaaSでの認証やID管理、監査機能について解説する。
前回は、Azure Active Directory（Azure AD）を具体例として、IDaaSの認証機能がどのように実装されているか解説した。今回は、引き続きAzure ADの認証やID管理、監査について見ていく。
| 構成要素 | 特徴 | 解説 | |
|---|---|---|---|
| 認証 | クラウドサービスとのID連携 | 接続検証済みのアプリケーションを選んで利用することで早期の立ち上げが可能 | |
| ID連携プロトコルへの対応 | OpenID Connectなどの最新プロトコルへ早期に対応しており新規サービスとの接続が可能 | ||
| 強固な認証方式への対応 | 多要素認証、リスクベース認証などオンプレミスでは対応が難しい方式に対応しており、セキュリティが強固 | ||
| ID管理 | クラウドサービスのID管理 | 接続検証済みのアプリケーションとのID自動同期が可能であり、個別にコネクタ開発が不要 | |
| 監査 | 認証ログ | 機械学習と組み合わせた不正アクセス検知などオンプレミスでは実装が困難な機能が実装できる | |
| IDaaSの構成要素と特徴 「構成要素」や「特徴」のリンクをクリックすると、詳細な解説にジャンプする。 | |||
認証
●強固な認証方式への対応
IDaaSを利用する場合、クラウド上にあるID基盤に企業のID情報を預けることになる。そのため、可用性や利便性の面で優位性は認めるもののセキュリティ上の不安が拭いきれない、という声が多いのも確かだ。
実際、最近もクラウド上でのパスワード管理サービスであるLastPassで、認証ハッシュが漏えいするという事故が発生している。
- パスワード一元管理のLastPassにハッキング、情報流出も（ITmediaエンタープライズ）
このように、インターネット上に配置されたID基盤は今後も攻撃対象となることが容易に想像できる。こうした状況においては、特に簡易なパスワードは簡単に推測・不正利用されることを前提として認証機能の設計を行う必要がある。その際に検討すべきなのが多要素認証やリスクベース認証である。
Azure ADの場合、次の機能が備わっている。
- モバイルアプリケーションやSMS、電話コールバックによる追加認証を行う「多要素認証」の機能
- 認証方法をアクセス条件によってコントロールする「アクセスルール」の定義を行う機能
これらの機能を利用すると、社外からのアクセスに限って追加要素での認証を要求する、というような細かなアクセス制御を行うことができる。
Azure ADの多要素認証の設定画面
これはAzure管理ポータルのAzure AD管理画面の1つ。
（1）信頼済みネットワークとして企業の外部ネットワークアドレスを設定することで、社外からのアクセスと社内からのアクセスを判別する。
Azure ADのアクセスルールの設定画面
同じくAzure AD管理画面の1つ。アプリケーション単位でアクセスルールを設定する。
（2）日本語訳が分かりにくいが、「作業中でない場合」が先の信頼済みネットワーク以外からのアクセスを指す。
Azure ADの認証用モバイルアプリケーション
上記のように多要素認証とアクセスルールを設定したアプリケーションに対し、社外からアクセスするとIDとパスワードだけでなく、追加要素による認証が要求される。これはAndroid端末にインストールした認証用アプリケーションで追加の認証をしている例。
（3）アプリケーションへのログイン時に、その確認要求がこのアプリケーションへプッシュ通知される。ここで［Verify］ボタンをタップすると認証が完了する。
＊モバイル用の認証アプリケーションはiOS用やWindows Phone用もあり、それぞれ以下からダウンロードできる。
・iOS用の「Azure Authenticator」（iTunes App Store）
・Android OS用の「Azure Authenticator」（Google Playストア）
・Windows Phone用の「Azure Authenticator」［英語］（Microsoft Store）
実際にアクセスルールを使ったWebアプリケーションやRemoteAppのアクセス制御については、筆者のブログ記事やビデオで解説しているので参考にしていただきたい（ビデオについては順次公開予定）。
【コラム】クラウド上に配置したID情報の安全性について
先に述べたように、日本の企業ではID情報をクラウド上に配置することに対する拒否反応が大きいのが現状である。そのようなケースでは、以下の2つの軸でID情報をオンプレミスに配置した場合と専門クラウド事業者に預けた場合のリスク分析をしてみていただきたい。
■内部不正の可能性
結局のところ、企業内情報の流出をさせるのは内部の運用者や管理者による犯行のケースが多い。内部不正に対する対策は当然必要ではあるものの、監査を含めて維持し続けるのは一般に企業にとって非常に高コストである。
一方でクラウド事業者ではISOなどの各種基準を満たした運用をしていることが多く、内部不正が起きにくい体制が維持されている。Microsoft AzureもISO 27018やPCI-DSSなど各種基準に対応している。
- Microsoft Azure セキュリティ センター: コンプライアンス 国際基準への業界認定の準拠（Microsoft Azureのトラストセンター）
■社外からのアタック（攻撃）の可能性
クラウドやモバイルの活用を行う上で、インターネットを含む社外からのアプリケーション利用は避けて通ることはもはや不可能である。オンプレミスの場合、結局Web Application Proxy（旧AD FSプロキシ）をDMZに配置してインターネット上にログイン画面を公開する場合がほとんどである。そのようなケースにおいてDoSアタックを含む各種攻撃に対応するだけのインフラを整備し、運用するのは非常にハードルが高い。
一方でクラウド事業者の場合は、各種攻撃にさらされることを前提としたインフラ投資と運用体制が整備されており、外部からの攻撃に対する耐性が高いと考えることができる。
上記を分かりやすく説明する際に筆者がよく使う例として、資産をタンス預金するか貸金庫に預けるか、という比較を挙げることが多い。
| タンス預金（＝オンプレミス） | 貸金庫（＝IDaaS） | |
|---|---|---|
| 狙われる危険性 | 狙われる可能性は低いかもしれない | そこに資産があることが分かりやすく、狙われやすい |
| 盗み出される危険性 | 貸金庫ほどのセキュリティ対策・体制を整備するのは困難。一度狙われると簡単に盗み出されてしまう | たやすく盗み出せないだけのセキュリティ対策や警備体制が敷かれており、実際に盗み出すのは非常に困難 |
| タンス預金（＝オンプレミス）と貸金庫（＝IDaaS）の危険性の比較 外部からの侵入（攻撃）を前提としている。 | ||
当然ながらタンス預金に関して貸金庫と同レベルのセキュリティ対策・体制を整備することは、コスト面からみても非現実的である。
Copyright© Digital Advantage Corp. All Rights Reserved.