はじめに
BIG-IP APM が搭載OS（TMOS）v11.3.0 から SAML2.0 に対応しました。上記により BIG-IP APM を採用したお客様のオンプレミス型認証基盤システムにおける、APM製品利用シーンが大きく変わることが予想されます。
何ができるのか
リバースプロキシでのシングルサインオン（SSO）認証後、内部Webアプリケーションを利用できるだけでなく、
- 既存認証基盤を活用し、
- 外部にパスワード情報を格納することなく、
- 外部クラウドサービス（Office 365 / Google Apps / Salesforce / サイボウズ等）を利用できる
ようになります。概要イメージは以下の通りです。
APMのSAML2.0対応で何が嬉しいのか
- 既存アカウント管理運用の継続
一度対象サービスとのSAML連携設定が完了した後は、管理者は基本的に今まで通りのアカウント管理を既存認証基盤に対して継続するだけです。導入時のインパクト、導入後の運用へのインパクト共に少ないことはITインフラシステムを採用する上で非常に大きなメリットと言えます。 - パスワード情報の外部保管が不要
クラウドサービス利用に踏み切れない１つの大きな理由としてパスワード情報の外部保管問題があります。SAML2.0を用いることでパスワードを外部保管することなくサービス利用することが可能になり、顧客のセキュリティポリシー上の課題を１つ解決することができます。 - サービス拡張性の向上
一度対象サービスとのSAML連携設定が完了した後は、同様の方法でSAML2.0対応したサービスを設定追加によって追加利用していくことができる拡張性を得ることができます。
SAML2.0について
インターネット上でマルチドメイン環境を想定した認証情報の交換について規定したもので、簡単に言うとサービス提供側（SP）が認証情報提供側（IdP）の情報を信頼しサービス提供する仕組みです。概要図は以下の通りです。
気を付けるべき点について
ここまでいい事ばかりに触れてきた気がしますので、注意点についてもお知らせしようと思います。SAMLに限った話ではありませんが、SSOでの認証には一度の認証で複数サービスを利用できるため、不正ログインされてしまった場合の影響度が、システム単位でのサイロ型認証を採用したシステムに比べて大きいというリスクが存在します。そのため、認証強化と利用者絞り込みの仕組みが必要となってきます。
例えば、従来通りのID＋固定パスワード（PW）の認証では、リスト型攻撃や、Open SSL の脆弱性などもあり、外部公開時のSAML認証へ採用するには不安が残ります。
また、顧客企業のシステム管理者の立場としては、利用者が特定ソースアドレスからしか来ないはずであるとか、配布した端末は特定のOSに限定できるとか、脱獄したスマートデバイスからは利用させたくない、社用端末であれば特定のプログラムが動作している、持ち出し端末はHDD暗号化ソフトが動いているはず、など様々な条件で絞り込み、利用者を絞り込むことができるはずです。
BIG-IP APM では以下の対策によってSSO認証時リスクを軽減することができます。
認証強化 対策例：複数要素認証
- ID＋固定PW＋ワンタイムトークン（APM単体対応可：要SMTP送信）
- ID＋固定PW＋クライアント証明書（APM単体対応可：要証明書管理）
- ID＋固定PW（PINコード）＋マトリクス型ワンタイムトークン（サードパーティ製品利用）
利用者絞り込み 対策例：エンドポイントセキュリティチェック
- 特定ソースアドレスから来ている通信のみ認証許可する
- 意図したOSのみ認証許可、また、OS単位で認証許可条件を変更する
- アンチウィルス製品が直近の定義ファイルを参照して動作している場合のみ認証許可する
- 脱獄したスマートデバイス（iOS / Android）は認証許可しない
- 特定プログラムが動作していない端末は認証許可しない
- HDD暗号化ソフトウェアが動作していない端末は認証許可しない
さいごに
BIG-IP APM で SAML2.0 を利用して利便性と安全性の両立を実現することで、オンプレミス認証基盤環境下で快適にクラウドサービス利用されてみてはいかがでしょうか。