ryouma-nagareのブログ

IT関連をメインに書いていきます。

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のセッション情報

  • セッション情報に様々な属性を登録し利用可能
  • Mac,Linuxのデバイス情報も持たせることが可能

できるだけSAMLで認証を行い、Webアプリはコンテンツに注力しましょう！

■まとめ

  • いきなり理想を目指さずにアクセスおよび認証ゲートウェイとしてAPMを用いる
  • 認証認可をできる限りAPMに委ね、最小限の属性で認可を行う

【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とは？

ここで紹介ムービー。見慣れた乱数表が出てきた。

●アンケートから

  • パスワード忘れの対応件数が減った
  • トークン管理の手間がなくなった
  • シングルサインオンが実現した
  • 外出時にモバイル端末で業務をすることが多くなった

●対応する連携プロトコル

●解決したい課題

  • リモートアクセスの際に固定パスワードではリスクがあるのでワンタイムパスワードを利用したい
  • デバイスの認証を人とひもづけたい
  • 人とひもづけた上でアクセスコントロールを行いたい
  • デバイス固有情報の収集を自動化したい。再発行や機種交換時も自動化した

APMが得たユーザアカウントとデバイス固有情報やADのパスワード等をAPMからパスロジへAPI経由で自動的にAttributeに登録することで解決！

  • OSごとに使用できる台数の制限も可能
  • 登録されていない端末からのアクセスを拒否する設定も可能

●あるべき姿

  • 誰が：PassLogic
  • 何で：APM＋PassLogic
  • 何を：APM が管理する。

【C-03：総SSL通信化に備える。SSLの技術動向とセキュリティ対策】

●SSLのトレンド

  • 2015年は25％程度がSSL通信。2017年末には半数がSSL通信になると想われる。

●総SSL化されているサイトは？

●SSLの関連動向

●SSL増加にともなう問題点とF5のSSL Everywhere

問題１．セキュリティ対策の陳腐化

  • 暗号化により、クライアント・サーバ以外は通信内容がわからない

  • 悪い通信も暗号化されることで捕まえづらくなる

  • セキュリティデバイスでのSSL処理の負荷

  • 次世代FW：7９％、次世代IPS：75％のパフォーマンスダウン
  • サンドボックス検査でSSL通信非対応のため、100％の検査ができない

　★SSL通信処理をBIG-IPに統合しましょう！

  • DISA事例：セキュリティ検査のための非SSL地帯

  • 復号化→FW／IPSで検査→暗号化してインターネットに出て行く構成が増えている。

  • 仮想化環境でのSSL処理オフロード

  • 仮想アプライアンスの横にBIG-IPをおいて、コネクション処理をオフロードする構成。

  • SNI拡張を利用して、BIG-IPでLTM＋ForwardProxyを使用して接続先ドメインによって出て行く回線を振り分けることも可能

問題２．暗号化の安全性

問題３．運用、管理の煩雑化

  • 証明諸管理、脆弱性対策、新基準への個別対応

●まとめ

  • 総SSL通信化に備えて・・・
  • SSL通信の可視化を構成の一部として組み込む
  • 安全なSSLを利用する SHA-2移行準備 堅牢なライブラリを使用
  • 手間のかかるSSL管理を一元化して運用コストの低減とパフォーマンスの確保を。

f:id:ryouma-nagare:20160212115254j:plain