F5 Japan Security Forum 2016 に行ってきました
久しぶりのセミナー参加です。
【C-01:APMで実現するWebアプリケーションシングルサインオン ~統合認証に必要な準備と構成事例紹介~】
https://f5.com/jp/products/modules/access-policy-manager のお話。
●伝えたいこと
- 統合認証基盤の整備
- Webアプリケーション認証ロジックの把握、調整
●背景
- 統合認証やSSOというキーワードでえBIG-IP APMについての引き合いが増えたが、APMの機能が発揮できない環境が散見される
- Webアプリケーションが必要とするID・PWの属性が網羅された認証基盤が存在しない
●統合認証基盤の整備
認証基盤の不整備により赤の他人にログインされ、情報流出を許す方が証跡からの対策観点で見ても、不正攻撃による流出よりも恐ろしい脅威と考える。
認証基盤統合の理想にむかうが…
- アプリごとに認証基盤が乱立
- 統合時の負荷影響が不明なため、すべてのアプリ。認証同時でないと変更できない。
- 既存システムの把握ができず、統合可能か判断不能
●IDの確認
- 各アプリでIDは共通か
- 異なる場合は空き属性があるか
●重複IDチェック
- 重複ID有無を確認できるか
- 重複IDの利用者を特定できるか
- 重複IDの変更方針を決定できるか
例:アプリAの「さとうこういち」さん とアプリBの「さとうこうじ」さんのアカウントがともに「k-satou」
●使用するパスワードの網羅性
- SSOの対象となるすべてのWebApplicationに用いるパスワードの共通化ができるか
■認可・アクセス管理属性
- ユーザ分類やアクセス管理に必要な属性があるか
■統合認証に必要なもの
- 必要になる属性をすべて網羅
- 利用者全員のアカウントを網羅 している認証基盤
■統合認証にむけて… ●立場による課題
- 顧客システム管理者とインテグレータ間の問題
- 既存詳細情報の把握と、将来実現したい要件の決定の押し付け合い。(どちらが持つか、という費用的な問題が大きい)
●APMを利用して実現する統合認証基盤
- 既存の認証基盤を流用したまま、認証ゲートウェイにAPMを配置する構成を移行後の構成計画とすることで実現性を高める。
- 重複IDなどの統合を棚上げできる
- 切り戻しが簡単
- 既存システムへの影響を最小限にできる。
- 最低限、どのアプリがどの認証サーバを参照するか、だけを把握すればすすめられる。
●参照先の分割
- VirtualServerを分けられる場合は、その単位で認証先サーバを選択
- 分けられない場合は、アクセスクライアント、認証サーバの属性値で分岐
- ex.接続クライアントのIPで条件分岐
- ex.LDAPのグルーブで分岐
■Webアプリケーションの認証構成の確認 ●Webブラウザ以外のインストールが必要なアプリケーション有無の確認
- 専用エージェント、クライアントアプリをインストールするか
- 必要な場合はそのアプリは統合できない可能性が高い
●認証方式の把握
- WebApplicationの認証方式確認
各アプリ自体での認証をやめられますか?
アクセスURLの把握
- ログインURL、リダイレクト先など
●認証属性と受け渡し
- 現状把握およびSSO実現後も必要な場合のため確認
- クエリストリングやHTTPヘッダを使用しているか?
●APMのセッション情報
できるだけSAMLで認証を行い、Webアプリはコンテンツに注力しましょう!
■まとめ
【A-03:BIG-IP APMとPassLogicで実現する高セキュア&高パフォーマンスのマルチデバイス認証インフラ 】
このセッションでは↓のムック本をいただきました。 http://www.amazon.co.jp/o/ASIN/4839958696/mynavibooks-22/www.amazon.co.jp
2015年1月でパスロジの発行ライセンスが100万IDを越えました!と、冒頭でアピール
これらを総合的にコントロール。
●PassLogicとは?
- トークンレスでワンタイムパスワードを実現
- トークンデバイス不要で、年間コストを70%ダウン
ここで紹介ムービー。見慣れた乱数表が出てきた。
●アンケートから
●対応する連携プロトコル
●解決したい課題
- リモートアクセスの際に固定パスワードではリスクがあるのでワンタイムパスワードを利用したい
- デバイスの認証を人とひもづけたい
- 人とひもづけた上でアクセスコントロールを行いたい
- デバイス固有情報の収集を自動化したい。再発行や機種交換時も自動化した
APMが得たユーザアカウントとデバイス固有情報やADのパスワード等をAPMからパスロジへAPI経由で自動的にAttributeに登録することで解決!
- OSごとに使用できる台数の制限も可能
- 登録されていない端末からのアクセスを拒否する設定も可能
●あるべき姿
【C-03:総SSL通信化に備える。SSLの技術動向とセキュリティ対策】
●SSLのトレンド
●総SSL化されているサイトは?
- 選択肢:マイクロソフト、Google、Yahoo、facebook、YouTube、twitter、Wikipedia、MSA、f5
- 今は全部です。SnowdenショックからSSL対応が一気に増えました
●SSLの関連動向
- 検索サイト
- HTTPSサイトの評価ランク向上
- サーバ証明書の多様化、無料化
- ドメイン認証、実在認証、EV証明書
- Let's Encrypt プロジェクト ・新しいプロトコル、レギュレーション HTTP/2、PCI DSS3.1
●SSL増加にともなう問題点とF5のSSL Everywhere
問題1.セキュリティ対策の陳腐化
暗号化により、クライアント・サーバ以外は通信内容がわからない
悪い通信も暗号化されることで捕まえづらくなる
- 次世代FW:79%、次世代IPS:75%のパフォーマンスダウン
- サンドボックス検査でSSL通信非対応のため、100%の検査ができない
★SSL通信処理をBIG-IPに統合しましょう!
- DISA事例:セキュリティ検査のための非SSL地帯
復号化→FW/IPSで検査→暗号化してインターネットに出て行く構成が増えている。
仮想化環境でのSSL処理オフロード
仮想アプライアンスの横にBIG-IPをおいて、コネクション処理をオフロードする構成。
SNI拡張を利用して、BIG-IPでLTM+ForwardProxyを使用して接続先ドメインによって出て行く回線を振り分けることも可能
問題2.暗号化の安全性
- SSLのサイトであれば安全?
- OpenSSLの脆弱性をついた攻撃がふえています。
https://www.ssllabs.com/ssltest/ でSSLサイトの安全性テストができます
SHA-1問題
- 安全性の低いアルゴリズムを利用したSSLサーバ証明書の廃止
App Transport Security
iOS9から、アプリの接続サーバはTLS1.2をサポートしなければならなくなった。
SSL Server Testの評価をあげるには?
- https://support.f5.com/kb/en-us/solutions/public/13000/100/sol13156.html を確認して適切な暗号化スイートを選択しましょう。
- 弱い暗号強度の暗号化スイートを無効化しましょう。
問題3.運用、管理の煩雑化
- 証明諸管理、脆弱性対策、新基準への個別対応
●まとめ
- 総SSL通信化に備えて・・・
- SSL通信の可視化を構成の一部として組み込む
- 安全なSSLを利用する SHA-2移行準備 堅牢なライブラリを使用
- 手間のかかるSSL管理を一元化して運用コストの低減とパフォーマンスの確保を。