BIG-IP APMとPassLogicを連携させて端末固有情報の登録を自動化する方法
Technorati タグ: APM,BIG-IP,iRules SSLVPN利用基盤の構築においてクライアント証明書を用いずにデバイスの制限を簡易な運用で実現できる仕組みを検討されており、下記のような要件があったとします。 ・SSLVPNを利用したい ・リスト型攻撃によるアカウント乗っ取りを防ぐ目的でワンタイムパスワードを利用したい ・メールを受信する形のワンタイムパスワードはそもそもメールを受信するシステムへのログインに使用するなど、メールが受信できない環境でのログインができないため今回は検討対象外 ・ユーザーに許可したデバイス以外からのアクセスは禁止したい ・デバイス登録のためにデバイス固有情報を1台1台調べて登録する作業は防ぎたい ・デバイスの特定のためにクライアント証明書による認証はSSLを終端するタイプのProxy経由でのアクセスもあることと、運用管理がより煩雑になるため行いたくない ・1ユーザーが使用するデバイスはひとり1台ではなくMac, Windows, Linux, iOS, Androidがあり最大5台(うちiOS/Androidは最大2台) ・ユーザーに紐づけるデバイスではなく、あらかじめ登録してある共有用デバイス (PC, Windows, iOS, Android)からのログインは無条件に認めたい ・ジェイルブレイクされたiOS端末、Android端末の登録は許可しない BIG-IP Access Policy Manager (以下APM)とパスロジ社のPassLogic Enterprise Edition 2.3.0(以下PassLogic)、そして本記事で紹介するAPMのAccess ProfileとiRulesでPassLogicのAPIと連携することでこれらの要件を満たすことができます。 システム要件 PassLogic Enterprise Edition 2.3.0 BIG-IP Access Policy Manager (APM) v12.0 HF1 このiRulesでは、Sideband Connectionを使用してAPMセッション変数のPassLogicのRADIUS Attribute登録を実現しています。 Technorati タグ: Japan 本設定サンプルでは、各OSで取得可能なデバイス固有情報 ・(任意の)NICのMACアドレス (Windows, Mac, Linux) session.machine_info.last.net_adapter.list.[0].mac_address ・マザーボードのシリアル番号 (Windowsのみ) session.machine_info.last.motherboard.sn ・(任意の)ハードディスクドライブのシリアル番号 (Windowsのみ) session.machine_info.last.hdd.list.[0].sn 詳しくは About Machine Info https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-visual-policy-editor-12-0-0/4.html も合わせてご参照ください。 ・iOSのUDID session.client.unique_id 詳しくは Support for using the BIG-IP Edge Client to check identifying information from Apple iOS client devices https://support.f5.com/kb/en-us/solutions/public/12000/700/sol12749.html も合わせてご参照ください。 ・AndroidのUnique ID session.client.unique_id 詳しくは Overview of session variable support for BIG-IP Edge Client for Android devices https://support.f5.com/kb/en-us/solutions/public/13000/700/sol13731.html も合わせてご参照ください。 APMでは下記のようなポリシーを作成し、Access ProfileからiRulesイベントを呼び出します。 iRulesではAPMセッション変数を使用してPassLogicのRADIUS Attributeへ情報を登録します。 when RULE_INIT { # Set the IP:Port of PassLogic Enterprise Edition set static::passlogicip "192.168.10.201" set static::passlogicport 7080 } when ACCESS_POLICY_AGENT_EVENT { # Check Shared Device (Required to set HW Info to DataGroup SharedDevices HWInfo:=DeviceKind) if { [ACCESS::policy agent_id] eq "IsSharedDevice" } { set uname [ACCESS::session data get session.logon.last.username] set hwinfo [ACCESS::session data get session.passlogic.hwinfo] set devkind0 [ACCESS::session data get session.passlogic.devicekind] if { [class match -value $hwinfo eq SharedDevices] eq $devkind0 } { log local0. "User $uname is accessed with shared device kind=$devkind ($hwinfo)" ACCESS::session data set session.isshareddevice "yes" } else { log local0. "User $uname is accessed with non-shared device kind=$devkind0 ($hwinfo)" ACCESS::session data set session.isshareddevice "no" } } # Device HW Information will be registed to PassLogic RADIUS Attribute if { [ACCESS::policy agent_id] eq "RegistHWInfoToPassLogic" } { # Get APM session variables set uname [ACCESS::session data get session.logon.last.username] set dom [ACCESS::session data get session.logon.last.domain] set rattr [ACCESS::session data get session.passlogic.attr] set devkind [ACCESS::session data get session.passlogic.devicekind] set hwinfo [ACCESS::session data get session.passlogic.hwinfo] set rewrite9 [ACCESS::session data get session.passlogi.setrewrite9] set newattr "" log local0. "username = $uname device=$devkind hw=$hwinfo" log local0. "Old Attribute = $rattr" if { $rewrite9 eq "yes" } { log local0. "Rewrite not device kind ($devkind) but any device (9)" set devkind 9 } # flag for change attribute set addd 0 foreach i [split $rattr |] { if { $i eq $devkind } { if { $addd == 0 } { # Generate new attribute data for regist new device set tstr $newattr set newattr "$tstr$hwinfo|" set addd 1 } else { set tstr $newattr set newattr "$tstr$i|" } } else { set tstr $newattr set newattr "$tstr$i|" } } if { $addd == 1 } { log local0. "New DeviceID ($hwinfo) for user $uname will be registered to PassLogic. New RADIUS Attribute=$newattr" set conn [connect -timeout 3000 -idle 30 -status conn_status $static::passlogicip $static::passlogicport ] log local0. "Connect returns: <$conn> and conn status: <$conn_status> " set conn_info [connect info -idle -status $conn] log local0. "Connect info: <$conn_info>" set data "GET /passlogic/api/admin?mode=useredit&uid=$uname&domain=$dom&attribute1=$newattr HTTP/1.0\r\n\r\n" set send_info [send -timeout 3000 -status send_status $conn $data] log local0. "Sent <$send_info> bytes and send status: <$send_status>" set recv_data [recv -timeout 3000 -status recv_status 1024 $conn] log local0. "Recv data: <$recv_data> and recv status: <$recv_status>" close $conn log local0. "Closed; conn info: <[connect info -status $conn]>" log local0. "PassLogic response is correct." if { $recv_data contains "PassLogic" } { set ret [string range [findstr $recv_data " " 0 " "] 6 10] log local0. "Result Code = $ret" ACCESS::session data set session.passlogic.result $ret switch $ret { "50300"{ ACCESS::session data set session.passlogic.error "PassLogic Error: err Invalid input data." log local0. "PassLogic Error: err Invalid input data." } "50301"{ ACCESS::session data set session.passlogic.error "PassLogic Error: err The user does not exist." log local0. "PassLogic Error: err The user does not exist." } "50302"{ ACCESS::session data set session.passlogic.error "PassLogic Error: err Update parameter is required." log local0. "PassLogic Error: err Update parameter is required." } "50400"{ ACCESS::session data set session.passlogic.error "PassLogic Information: notice User information has updated successfully. New DeviceID ($hwinfo) for user $uname was registered." log local0. "PassLogic Information: notice User information has updated successfully. New DeviceID ($hwinfo) for user $uname was registered." } "50499"{ ACCESS::session data set session.passlogic.error "PassLogic Error: crit System error occurred." log local0. "PassLogic Error: crit System error occurred." } } } } else { ACCESS::session data set session.passlogic.result "NG" } } } 詳しい設定手順やAccess Profile、iRulesサンプルは下記よりダウンロードできます。 https://f5.com/Portals/1/PDF/JAPAN/devcentral/PassLogic230_APM12_AP_iRule_v1.zip
Protecting Beyond DNS Flood & DDoS
The recent slate of cyber-attacks involving DNS and NTP systems has again prompted questions about the comprehensiveness of DNS infrastructure’s security protection. Besides mitigating volumetric attacks such as DNS flood & DDoS, many organizations have realized the need for a more comprehensive DNS security protection, which helps in preventing DNS-related security frauds and non-volumetric based attacks such as amplification and cache poisoning attacks. On DNS Amplification & DNS Reflection Attacks You might concur that increasing DNS performance with adequate DNS rate limiting mechanism is probably one of the best approaches to tackle the problem of overwhelming DNS traffic and DNS DoS attacks. However, this does not address the issue of DNS Amplification and DNS reflection attacks, which has been made popular through the Spamhaus-Cyberbunker attack incident. In this incident, CyberBunker took the advantage of open DNS resolvers to launch DNS amplification attacks, causing Spamhaus to be unreachable at times. DNS amplification and reflection attacks are typically sent to DNS servers as legitimate DNS request, in hope to receive large data size responses. The huge data size responses will eventually use up all the available bandwidth causing congestion to genuine DNS queries and responses. As such, DNS query rate limiting mechanism and higher QPS performance will not be able to counter the attack since the attacks typically come in small numbers of DNS requests. One of the ways to limit such attacks is to filter the request based on query type. Typically, DNS amplification and reflection attacks will request for ‘TXT’ or ‘ANY’ Query Type which tends to return responses with significant data size. By applying bandwidth rate limit to these query type request and large-data-size query responses, we will be able to prevent bandwidth congestion caused by these attacks. Worried about the complexity of the bandwidth rate limiting solution? Well, it only takes less than 10 lines of iRules (shown as below) on F5 DNS platform to get this enforced and implemented. when DNS_REQUEST { if { ([DNS::question type] eq "TXT") } { rateclass dns_rate_shape } } when DNS_RESPONSE { if { ([DNS::len] value > 512) } { rateclass dns_rate_shape } } Diagram 1: DNS Reflection attacks blocking genuine users from accessing LDNS server. Cache Poisoning Attacks DNSSEC is poised as the eventual and ultimate solution to counter DNS cache poisoning attacks. Though the adoption rate of DNSSEC is encouraging, it takes all parties to deploy DNSSEC signing and validation to fully protect against cache poisoning. While waiting for DNSSEC adoption rate to mature, is there any interim solution to reduce or prevent cache poisoning attacks? Based on DNS RFC standards, name servers are required to treat domain names request with case-insensitivity. In other words, the names www.foo.com and WWW.FOO.COM should resolve to the same IP address. However, most name servers will preserve the original case when echoing back the domain name in the response. Hence, by randomly varying the case of characters in domain names queried, we will be able to add entropy to requests. With this verification mechanism, the name server response must match the exact upper and lower case of every character in the name string; for instance, wWw.f5.CoM or WwW.f5.COm, which significantly reduces the success rate of cache poisoning attacks. With F5’s DNS solution, this mechanism can be enabled with just a check box on the management pane. The packet capture of the query case randomization process by F5 DNS is shown as below. As depicted in the diagram, for queries to www.google.com, F5 Cache DNS will randomize the character case of the query prior sending the query to Google’s authoritative DNS server. This greatly reduces the chances of unsolicited queries matching the domain name and DNS request transaction ID, which causes the poisoning of cached DNS records. Diagram 2: Character case randomizer in F5 DNS solution dramatically reduces the possibilities of DNS cache poisoning attacks DNS is among the hoariest of internet services that is still widely used today. Its usage continues to grow due to its simplicity and proliferation of smart devices. Hence, it is truly important that proper solution design and architecture approach are being put in place to protect the infrastructure. After all, the protection investment might be only a fraction of what you are paying for during an attack.
BIG-IP ASMで対応するOWASP Top 10 - 2017年版
この投稿は、F5ネットワークスのシニア・ソリューション・デベロッパーであるPeter Silva のブログ投稿「The OWASP Top 10 - 2017 vs. BIG-IP ASM 」を元に、日本向けに再構成したものです。 OWASP Top 10の2017年正式版がリリースされましたので、BIG-IP ASMのWAF機能でどのくらい対応できるか概要を紹介したいと思います。 まず最初に、2013年版と2017年版の比較です。いくつかの新規項目の追加と、既存項目の統合が行われています。 では、BIG-IP ASMの対応状況を見ていきましょう。 Vulnerability BIG-IP ASM Controls A1 Injection Flaws インジェクション Attack signatures Meta character restrictions Parameter value length restrictions A2 Broken Authentication and Session Management 認証とセッション管理の不備 Brute Force protection Credentials Stuffing protection Login Enforcement Session tracking HTTP cookie tampering protection Session hijacking protection A3 Sensitive Data Exposure 機密データの露出 Data Guard Attack signatures (“Predictable Resource Location” and “Information Leakage”) A4 XML External Entities (XXE) XML外部実体参照(XXE) Attack signatures (“Other Application Attacks” - XXE) XML content profile (Disallow DTD) (Subset of API protection) A5 Broken Access Control アクセス制御の不備 File types Allowed/disallowed URLs Login Enforcement Session tracking Attack signatures (“Directory traversal”) A6 Security Misconfiguration セキュリティ設定のミス Attack Signatures DAST integration Allowed Methods HTML5 Cross-Domain Request Enforcement A7 Cross-site Scripting (XSS) クロスサイトスクリプティング(XSS) Attack signatures (“Cross Site Scripting (XSS)”) Parameter meta characters HttpOnly cookie attribute enforcement Parameter type definitions (such as integer) A8 Insecure Deserialization 安全でないデシリアライゼーション Attack Signatures (“Server Side Code Injection”) A9 Using components with known vulnerabilities 既知の脆弱性を持つコンポーネントの使用 Attack Signatures DAST integration A10 Insufficient Logging and Monitoring 不十分なロギングおよび監視 Request/response logging Attack alarm/block logging On-device logging and external logging to SIEM system Event Correlation 新規に追加された「A4: XML外部実体参照（XXE）」の項目についても、すでにシグネチャで対応しています。 200018018 External entity injection attempt 200018030 XML External Entity (XXE) injection attempt (Content) また、XXE攻撃は、XMLプロファイルによって汎用的な防御も可能です。 （DTDsを無効にして、"Malformed XML data"バイオレーションを有効にします） また「A8:安全でないデシリアライゼーション」の対応策として、こちらも多くのシグネチャがすでに提供されています。 これらシグネチャの多くは、下記のように“serialization” や“serialized object” といった名前が含まれています。 200004188 PHP object serialization injection attempt (Parameter) 200003425 Java Base64 serialized object - java/lang/Runtime (Parameter) 200004282 Node.js Serialized Object Remote Code Execution (Parameter) 以上、OWASP Top10 2017年版のリリースにともなう、BIG-IP ASMのWAF機能の対応状況のご紹介でした。 関連リンク： What’s New In The OWASP Top 10 And How TO Use It BIG-IP ASM Operations Guide
HTTP/2がもたらすビジネス上の意義
パフォーマンスの確保は、アプリケーションにとって重要な課題です。特にモバイル アプリケーションでは最重要課題だと言っても過言ではないでしょう。これまで行われてきた数々の調査結果を見れば、誰でもこの結論に達することができるはずです。アプリケーションが5秒以内に反応しなければ、一般消費者も企業ユーザも、同じように苛立ちます。なかでも消費者がモバイル アプリケーションを使って購入などを行う場合には、パフォーマンスの低さが致命傷になる危険性があります。 このようなパフォーマンスに対する要求への対応を念頭に入れて開発されたのがHTTP/2です。 HTTP/2には、これまで開発者がHTTP/1.1におけるパフォーマンス改善策として頻繁に使用した結果、標準的な手法になっていったものが数多く実装されています。例えば、小さな画像を文字列に変換してHTMLやCSSに埋め込むことでHTTPリクエストを削減するインライン化や、小さなファイルの結合（Concatenation）、静的ファイルを別のドメインから読み込むことで同時接続数の上限を最大化するドメイン シャーディングなどの手法です。これらはいずれもパフォーマンス改善に貢献しましたが、残念ながら開発者と運営者の双方に対し、大きな“技術的負債”をもたらす結果となりました。 HTTP/1.1が生み出した“技術的負債” ここで言う“技術的負債”とは、特定の技術や製品、アーキテクチャを採用することでもたらされた、その後の開発や運営へのマイナスの影響を意味しています。また特定のソリューションを、アーキテクチャ内のどこに実装するかの判断も、技術的負債の要因になる可能性があります。 例えば、HTTP/1.1の制約を回避するために利用されてきたインライン化やファイル結合は、ネットワーク上のキャッシュの利用を不可能にしてしまいました。またこれらのインライン化されたイメージやファイル結合は、すべてのアプリケーションに反映する必要があるため、アプリケーションのライフサイクルにも注意を払う必要があります。つまりこれらの手法を使うことで、アプリケーションのモジュール性が失われてしまったのです。このような技術的負債は、対象となるアプリケーションが使われ続ける限り、開発者や運営者を悩まし続けることになるでしょう。 金銭的負債と同様、技術的負債にも対応が必要です。そのまま放置しておけば“利子”が発生するからです。この利子はアプリケーションの変更やアップデートが行われるたびに蓄積され、開発者は必要以上の時間と注意力を費やすことになります。またテストのためのリソースも必要になり、ネットワークやコンピューティングのリソースも消費します。その結果、企業はイノベーションや成長のためではなく、負債への対応に時間を費やすことになり、競争力を生み出す新しい技術や手法、アーキテクチャ上のコンセプトなどを活用することが困難になります。 HTTP/2への移行が可能にする負債からの解放 HTTP/1.1で生じた技術的負債は、将来的にHTTP/2へと移行することで解消できます。HTTP/2は、技術上・プロトコル上の幅広い制約に取り組んだ結果、開発者が過去の迂回策を捨て、新たな選択肢を手に入れることを可能にしたからです。そしてこれらの新たな選択肢には、技術的負債は伴いません。もちろん既存アプリケーションはこれまでの負債を抱えたままになりますが、HTTP/2対応のアプリケーションへの移行や置き換えを進めることで、HTTP/1.1が生み出してきた制約から、開発者も運営者も解放されていくでしょう。 このように、HTTP/2の意義は高速化だけではありません。技術的負債による制約から開発者や運営者を解放し、企業にパフォーマンス改善のための新たな手段を活用するチャンスをもたらすことも、重要な意義だと言えます。技術やアーキテクチャ面での負債を生じさせにくい手段を活用すれば、企業はアプリケーション競争において、勝利を収めやすくなるのです。 新規予算のうち、イノベーションに使われた割合はわずか3分の1未満であり、その他は単なる改善に費やされているとCIO達は認めています。一般企業向けのF5 DDoSリファレンス アーキテクチャ
今回投稿されたブログは、F5ネットワークスのテクノロジー・エバンジェリストであるDavid Holmesのブログ投稿「The F5 DDoS Reference Architecture - Enterprise Edition」を元に、日本向けに再構成したものです。 DDoSによる攻撃は依然として続いており、現在でもDDoS攻撃に対する防御は重要課題であり続けています。すでにこのDevCentralでは、グローバル金融機関向けのDDoSリファレンス アーキテクチャを紹介していますが、一般企業にとってもDDoS攻撃対策は欠かせません。そこで今回は、一般企業（エンタープライズ）向けのDDoSリファレンス アーキテクチャを提示し、グローバル金融機関向けのDDoSリファレンス アーキテクチャとどのように異なるのかを解説します。 この展開シナリオは大量の受信トラフィックだけではなく、社内ユーザからの送信トラフィックもある程度存在することを前提にしています。 グローバル金融機関向けとの差異 グローバル金融機関向けのリファレンス アーキテクチャとは、以下の点が異なっています。 1.まず図の右上に社内ユーザ（Employees）が書き込まれており、社内ユーザから社外に対してユーザ生成トラフィックが発信されています。このトラフィックは次世代ファイアウォール（Next-Generation Firewall）、あるいはWebセキュリティを提供する何らかのデバイスを通過した後、データセンターのメインのファイアウォールから、インターネットへと出ていきます。 2.一般企業のユースケースでは、DNSサービスが攻撃防御の第1段に集約されるか、少なくとも第1段のファイアウォール マネージャによって保護されるケースが一般的です。ここに示した図では、DNSサービスがBIG-IPに集約されています。 3.グローバル金融機関向けのリファレンス アーキテクチャでも解説したように、金融機関では暗号鍵を外部ネットワークから隠すため、SSLを第2段のところで終端すべきです。しかし一般企業の場合にはそれほど厳密に考える必要はないため、自由度はより高くなります。SSLの終端場所が第1段になるか第2段になるかの可能性は、ほぼ半々になります。 4.一般企業のユースケースでは、Single-Sign OnやVDI、SSL-VPNサービスを提供するAccess Policy Manager（APM）の活用が、大きなメリットをもたらす可能性があります。これらのサービスによって、社内ユーザの利便性向上とセキュリティ強化を両立できるからです。グローバル金融機関のユースケースでは、そのメリットはそれほど顕著ではありません。 グローバル金融機関向けとの共通点 なおこのアーキテクチャの本質である、2段構成の防御という点については、グローバル金融機関向けのリファレンス アーキテクチャと共通しています。第1段ではDDoSを認識するネットワーク ファイアウォールによってネットワーク攻撃を防御し、拡張性に富んだ第2段でアプリケーション攻撃を防御します。 F5のDDoSリファレンス アーキテクチャの詳細については、新しいF5 Synthesisリファレンス アーキテクチャ サイトをご覧ください。BIG-IPとADFSパート3 - 「ADFS、APM、およびOffice 365シッククライアント」
パート3があるという話はしていませんでした。しかしこのシリーズの内容はパート2で止めておくには面白すぎますし、実はカバーしておくべき重要なセクションがもうひとつありました。 まず、パート1と2について簡単に復習します。パート1ではADFSとADFSProxyファームの負荷分散による、ハイアベイラビリティと拡張性の確保について説明しました。パート2では、ADFSProxyレイヤの代替としてのAccess Policy Manager（APM）（英語）を取り上げました。この方法はソリューションのセキュリティと柔軟性を高めるだけでなく、インフラストラクチャの簡素化にも貢献します。 このシリーズをフォローしていただいた方なら（たぶん）覚えておられるように、パート2ではOffice 365をユースケースとして、Big-IPとAPMがどのようにOutlook Web Access（OWA）へのSSOサインオンを実現するかを示しました。しかしOutlookとLyncクライアントを含むシッククライアント（thick client - アクティブなプロトコルとアクティブなプロファイル）の場合にはもう少し状況が複雑になります。以下にこれを説明します。 パッシブプロトコル - （Outlook Web App） WS-Federationパッシブプロトコルを使うクライアントの（主としてブラウザベースの）プロセスは以下のとおりです。 クライアントがOffice 365リソースへのアクセスを試みます。 クライアントはMicrosoft Federation Gatewayにリダイレクトされます。 クライアントは社内のフェデレーションサービス（ADFS）にリダイレクトされます。 ADFSサーバはこのクライアントをアクティブディレクトリに対して認証します。 ADFSサーバはクライアントに対し署名済みのセキュリティトークンとリソースパートナーへのクレームセットを含む認証クッキーをクライアントに提供します。 クライアントはMicrosoft Federation Gatewayに接続し、そこでトークンとクレームが検証されます。Microsoft Federation Gatewayは新しいセキュリティトークンをクライアントに提供します。 クライアントは新しい認証クッキーをそれに含まれるセキュリティトークンと共にOffice 365リソースに提示してアクセスを行います。 上記のケースでは、ADFSはWS-FederationプロトコルとSAMLを使用しています。このタイプの接続は、一般にBIG-IPのAPMを使ってADFSへの接続をプロキシ化することによって大きく改善されます。 アクティブプロトコル - （OutlookおよびLyncクライアント） OutlookやLyncのようなクライアント（外部クライアント）によるやり取りは少し異なります。この場合のプロセスはアクティブプロトコル、WS-Trust、およびSOAPを使用します。 クライアントがOffice 365リソースへのアクセスを試み、認証情報を提供します。 Office 365はMicrosoft Federation Gatewayに認証を求めます。 Microsoft Federation Gatewayはクライアントに代わってADFSサービスに連絡し、認証情報を提示します。 ADFSはクライアントの認証情報をアクティブディレクトリにより認証します。 ADFSはMicrosoft Federation Gatewayにトークンを提供します。 Microsoft Federation GatewayはOffice 365にトークンを提供し、クライアントによるリソースへのアクセスを可能にします。 簡単に言えば、クライアントがADFSにトークンを要求して取得するための作業を行う代わりに、Microsoft Federation GatewayがADFSとのやり取りを直接行います。クライアントはADFSとは接続しないため、APM（またはどのプロキシサービスも）は使用できません。 ここで問題が生じます。Big-IP APMの背後でADFSを展開している場合、シッククライアント（OutlookやLync）の認証のためMicrosoft Federation Gatewayが直接アクセスを行い、かつパッシブな接続（ブラウザベースと社内のLync）については事前認証を行えるようにするにはどうすれば良いでしょうか？これはiRuleを使うことにより簡単に解決できます。 APMはiRuleをバイパス MS Federation Gatewayに直接アクセスできるよう、iRuleをひとつ作成し、それを本シリーズのパート2で作成したADFS仮想サーバに割り当てます。このiRuleはHTTP_REQUEST（英語）イベント（システムがHTTPリクエストのパーシングを行うことによって起動）を使ってURIを分析します。適切なリクエストを受領するとACCESS::disable（英語）コマンドが呼び出されてアクセスポリシーが無効になり、リクエストの通過が許可されます。サードパーティ製プロキシの要件についてはマイクロソフトが発行するガイドも参照してください。以下の基本的なiRuleを作成し、社外のADFS仮想サーバに割り当ててみてください。 1: when HTTP_REQUEST { 2: 3: # For external Lync client access all external requests to the 4: # /trust/mex URL must be routed to /trust/proxymex. Analyze and modify the URI 5: # where appropriate 6: HTTP::uri [string map {/trust/mex /trust/proxymex} [HTTP::uri]] 7: 8: # Analyze the HTTP request and disable access policy enforcement WS-Trust calls 9: if {[HTTP::uri] contains "/adfs/services/trust"} { 10: ACCESS::disable 11: } 12: 13: # OPTIONAL ---- To allow publishing of the federation service metadata 14: if {[HTTP::uri] ends_with "FederationMetadata/2007-06/FederationMetadata.xml"} { 15: ACCESS::disable 16: } 17: } 以上です。単純明快ですね。ご自分で試してみてその結果を教えてください。ここでは社外からのアクセスを取り扱っているため、外部アクセスの識別とブロックのためのADFS 2.0のサポートについては触れませんでした。この高度な機能に関心がある場合はマイクロソフトが発行するガイド（英語）を参照してください。Big-IPとADFSパート2 - APM - ADFS Proxyに代わる選択肢
このパートではADC（Application Delivery Controller）について説明します。先のパート1ではBig-IPの優れた負荷分散機能を使って社内ADFSファームと境界部ADFSProxyファームの両方を展開することにより、ハイアベイラビリティと拡張性を確保しました。しかしBig-IPはこれ以外にもさまざまな方法でアプリケーションデリバリに貢献します。このパート2ではADFSProxyレイヤの代わりとしてAccess Policy Manager（APM） モジュールを使用します。この手法の事例として、最も一般的な使用ケースであるウェブベースのMicrosoft Office 365（英語）アプリケーションとフェデレーション化を行い、このアプリケーションへのシングルサインオンを可能にするためADFSを展開する場合を考えてみます。 このADFSProxyサーバの目的は、インターネットからアクセスできないADFSサーバへの要求を受領し、それを転送することです。パート1で述べたように、ハイアベイラビリティを実現するには少なくとも2台のプロキシサーバに加えて負荷分散ソリューション（もちろんF5 Big-IP）が必要です。F5のアプライアンスにAPMを実装することにより、これらのサーバが不要になるだけでなく、境界部で事前承認を行い、またクライアントサイドでのチェックなど高度な機能（アンチウィルスのバリデーション、ファイアウォールの検証など）の導入によりおそらくよりセキュリティを強化した展開が実現します。 前提事項および製品展開のための資料 - この展開シナリオでは、読者にBIG-IP LTMモジュールの管理に関する一般的な知識と、APMモジュールに関する基本的な理解があることを想定しています。詳細やガイドが必要な場合はF5のサポートサイトASKF5（英語）を参照してください。下図は社内外のクライアントがADFS経由でOffice 365にアクセスする場合の典型的なプロセスフローを示しています（受動的制御、「ウェブベース」のアクセス）。 両方のクライアントがOffice 365リソースへのアクセスを試みます。 両方のクライアントがそのリソースのフェデレーションサービスにリダイレクトされます（注：このステップはMicrosoft Outlookなどのアクティブクライアントの場合には省略されることがあります）。 両方のクライアントは社内のフェデレーションサービスにリダイレクトされます。 ADFSサーバがアクティブディレクトリに対してクライアントを認証します。 ・社内クライアントはADFSサーバファームのメンバーに直接負荷分散されます。 ・社外のクライアントは： - APMのカスタマイズ可能なサインオンページ経由でActive Directoryに対し事前認証されます。 - 認証されたユーザはADFSサーバファームのメンバーにリダイレクトされます。 ADFSサーバは、署名済みのセキュリティトークンとリソースパートナーへのクレームセットを含む認証クッキーをクライアントに提供します。 クライアントはMicrosoft Federation Gatewayに接続し、そこでトークンとクレームが検証されます。Microsoft Federation Gatewayが新しいセキュリティトークンをクライアントに提供します。 クライアントは新しい認証クッキーをそれに含まれるセキュリティトークンと共にOffice 365リソースに提示してアクセスを行います。 仮想サーバとプールメンバー - （社内と社外の）すべてのユーザは同じBig-IPを経由してADFSサーバファームにアクセスしますが、その要件とそれ以降のユーザエクスペリエンスはそれぞれ異なります。社内の認証されたユーザはADFSサーバファームに直接負荷分散されますが、社外ユーザは（APM経由で事前承認を得た後にADFSファームのメンバーへのアクセスを許可されます。このため2つの仮想サーバが使用され、その1つは社内アクセスに、もう1つは社外からのアクセス専用となります。社内と社外の仮想サーバには、いずれも同じ社内ADFSサーバファームプールが関連付けられます。 社内の仮想サーバ - 社内ADFSファームの仮想サーバ設定については本シリーズのパート1をご覧ください。 社外の仮想サーバ - 社外の仮想サーバのコンフィグレーション設定は、本シリーズのパート1に記載した仮想サーバの場合と同様です。これに加え、APM Access Profile（下記設定のハイライト部分を参照）が仮想サーバに割り当てられます。 APMのコンフィグレーション設定 - 社外ユーザが社内のADFSファームへのアクセスを許可されるのに先立ち、以下のAccess Policy Manager（APM）コンフィグレーションが作成され、社外向けの仮想サーバに関連付けられます。先に述べたように、APMモジュールは事前承認に加え、クライアントサイドでのチェックやシングルサインオン（SSO）など高度な機能も提供します。もちろんこれらはさまざまな機能のほんの一部に過ぎません。ASKF5（英語）にはクライアントサイドのチェックに関する詳細が記載されています。 AAAサーバ - ADFSアクセスプロファイルはActive Directory AAAサーバを使用します。 アクセスポリシー - ADFSアクセスプロファイルには以下のアクセスポリシーが関連付けられています。 ログオンページの表示に先立ち、クライアントマシンにアップデート済みのアンチウィルスソフトウェアが存在するかチェックします。クライアントにアンチウィルスソフトウェアが存在しないか、あるいはウィルス定義が（30日以内に）アップデートされていない場合、ユーザはリダイレクトされます。 オンプレミスとOffice365 ExchangeユーザのいずれにもシングルURLのOWAアクセスを提供するため、ADクエリとシンプルなiRulesが使用されます。 SSO のコンフィグレーション - ADFSアクセスポータルは複数の認証ドメインについてNTLM v1 SSO プロファイルを使用します（下図参照）。複数のSSO ドメインを使用することにより、クライアントは一度認証するだけでExchange OnlineやSharePoint Onlineなどホストされたアプリケーションと、オンプレミスでホストされたアプリケーションの両方にアクセスすることができます。これをさらに促進するには同じSSOコンフィグレーションを使う複数の仮想サーバ（ADFS、Exchange、SharePoint）を展開します。 接続プロファイル - デフォルトの接続プロファイルをベースとする接続プロファイルが社外仮想サーバに関連付けられます。 たくさんの情報が含まれていましたがいかがでしたでしょうか。これがAPMや負荷分散以外にBig-IPを使って行えるさまざまなことについて、さらに理解を深めるきっかけとなったことを期待しています。ハイブリッド環境が要求する“よりスマートな”DNS
ハイブリッド環境で変わるDNSの役割 クラウドは実に多くの環境を変化させており、私たちはあらゆる業務領域でIT戦略の見直しを迫られています。アプリケーションの開発・展開の方法は、DevOpsへと変化しつつあり、IT業界のビジネス モデルも従来のライセンス モデルから、電気や水道のような使用量に基づくサブスクリプション モデルへと変わりつつあります。 しかし、可用性やパフォーマンス、セキュリティに対する要求は、依然として変わりません。企業ITがクラウドにシフトしているのと同様に、消費者によるモバイルやウェブアプリケーションの利用も激増しています。IT環境が劇的な変化を続ける中、可用性の不足やパフォーマンスの低さは、アプリケーションの成否を分ける大きな要因になります。 ハイブリッド環境の導入・活用が進むにつれて、以前よりも可用性やパフォーマンスの確保は難しくなっています。ハイブリッド環境においては、複数のパブリック クラウドやデータセンターにアプリケーションが拡散しています。そのため、可用性やパフォーマンスは、様々な変動要因によって左右されざるを得ない状況が生まれています。だからこそ、ハイブリッド環境においても可用性やパフォーマンスを維持するためには、高いインテリジェンスが求められるのです。 そのインテリジェンスを提供する要素として着目したいのが、DNSの存在です。 DNSはインターネットの全てをカバーした電話帳だといえます。言い換えれば、世界中のあらゆるアプリケーションやモノ、機器がどこにあるのかを特定するためのバックボーンです。DNSがなければあらゆるアプリケーションは、その機能を果たせなくなります。DNSの役割は、極めてクリティカルなものなのです。 DNSに求められるインテリジェンスとは DNSが高いインテリジェンスを備えることは、ハイブリッド環境における可用性やパフォーマンス、セキュリティを確保する上で、重要な意味を持ちます。ハイブリッド環境では、「目的のアプリケーションがどこにあるのか」という要求に応えるだけではなく、クライアントのある場所やアプリケーションの状況を正確に把握し、場合によっては、異なるサイトに置かれたアプリケーションにアクセスさせる、といった判断をする必要に迫られるからです。 このインテリジェントな判断を可能にしているのが、F5のBIG-IP DNSです。BIG-IP DNSは容量が大きく拡大されただけではなく、ハイブリッド環境全体にわたってアプリケーションの状況やパフォーマンスを監視し、他の全てのBIG-IP DNSと連携しながら、それぞれのクライアントをどこへアクセスさせるかをリアルタイムで判断します。 時には、DNS DDoS攻撃を防止するための対応策として、「クライアントからの問い合わせに応答しない」という判断を行うこともあります。 DNS DDoS攻撃の被害は、拡大の一途をたどっています。最近のある調査によれば、「DNSベースのDDoS攻撃は2014年に激増しており、2015年も攻撃が激しさを増していることは明白である」と報告されています。日本でも、2014年5月から7月にかけて、国内のインターネットサービスプロバイダがDNS DDoS攻撃を受けて、数週間にわたり通信障害が発生した事件がありました。また別のレポートでは、極めて大量のデータを送りつける“ハイボリュームなDDoS攻撃”が、2015年も継続的に行われていると指摘されています。昨年は、DNSハイジャックをはじめとするDNSベースの攻撃によって、複数の著名企業が重大な問題に直面しました。今後、このような状況がさらに悪化することは、間違いないでしょう。 つまりDNSには、アプリケーションに影響を及ぼし得る全ての攻撃を検出すると同時に、防御するためのインテリジェンスも不可欠なのです。 DNSのセキュリティをどう確保するか 本来の定義においても設計・実装においても、DNSにはオープンであることが求められます。一般のユーザーが利用するウェブアプリケーションと同様、DNSもオープンな状態に維持されるとともに常に利用可能でなければなりません。ハイボリュームなDDoS攻撃を回避するためにDNSが停止されれば、本来の機能を失うことになります。このような状況においてDNSには、2つの機能を同時に実現することが求められています。「攻撃を検出して自らを保護する」機能と「正当な要求には迅速に対応する」機能です。 ここで言う“迅速”とは、“極めて迅速である”ということです。モバイル アプリケーションのレスポンスを悪化させる要因の1つとして、DNSのルックアップ時間はしばしば非難されています。DNSの応答速度は、速ければ速いほど快適性をもたらします。しかし、攻撃からDNS自身を守るための処理は、応答速度の悪化につながりかねません。 例えば、DNSレコードの破壊を防止するための一般的な手法として、プロトコル検証があります。しかし、プロトコル検証に時間がかかってしまうと、応答速度を悪化させてユーザーの快適な体験を損なう結果につながりかねません。プロトコル検証は可能な限り、高速かつ正確に行うべきなのです。BIG-IP DNSは、プロトコル検証をハードウェアで行うことにより、この課題をクリアしています。ソフトウェアのみの場合に比べて、処理速度は7倍も高速化されています。BIG-IP DNSを使用することで、攻撃に耐えるセキュリティ能力を確保しながら、快適なアプリケーション利用が可能になります。 また、BIG-IP DNSは、ハードウェアによってDNSキャッシュを拡張することも可能です。ソフトウェアによるキャッシュに比べて、この専用ハードウェアは最大5倍のサイズを確保することで、より高速な応答を可能にします。DNSの応答時間が大幅に短縮されれば、モバイル アプリケーションをスワイプした後の画面表示や最新データへの更新にかかる時間も短縮され、より快適なアプリケーション利用が可能になります。 このようにDNSは、単に「アプリケーションがどこにあるのか」を見つけ出すためだけのツールではありません。どのアプリケーション、どのサービス、あるいは、どのサイトへとクライアントを振り向けるかについて、インテリジェントな判断をスマートに下すための基盤なのです。ハイブリッド展開の柔軟性を犠牲にすることなく、可用性やパフォーマンスを適切にコントロールするとともに、高いセキュリティを確保するためには、DNSの役割を深く理解し、積極的に活用することが求められています。Big-IPとADFSパート1 - ADFSファームの負荷分散
企業がクラウドへの移行を進める様子は、かつて開拓者たちが次々に幌馬車を仕立てて西への道を辿ったことを思い起こさせます。今クラウドに移行している企業はもはや開拓者とは呼べないかも知れませんが。クラウドへの集団移民が起こっているとまでは言えないものの、Office 365をはじめとしたクラウドベースのサービスを導入する企業が増えてきていることは事実です。 このような状況において、社外にあるリソースへのシームレスな、あるいは少なくとも比較的シームレスなアクセスを提供できるでしょうか？この回答のひとつにフェデレーションがあり、マイクロソフトを使っている企業ならADFS（Active Directory Federation Services）をその最新のソリューションとして利用することが可能です。この場合、ADFSサーバはセキュリティトークン サービスとして機能し、ディレクトリによって承認されるクライアントのシングルサインオン（SSO）を社外のリソースにも拡大します。クラウドベースのアプリケーションやフェデレーションの普及と歩調を合わせ、ADFSの役割も重要になってきています。以下にADFSサーバファームとADFS Proxyサーバファーム（社内に置いたADFSファームに外部からアクセスする場合に推奨）の典型的な展開シナリオを示しています。 警告：ADFSサーバファームを利用できない場合、フェデレーションによるリソースへのアクセスには制約が加わります。ハイアベイラビリティ、パフォーマンス、および拡張性を確保するためには、F5 Big-IPをLTM（Local Traffic Manager）と共に展開し、ADFSとADFS Proxyサーバファームの負荷分散を行います。F5のBig-IPは負荷分散とアプリケーション配信のための非常に優れた手段のひとつです。 それでは次に技術面を説明します。このブログのパート1では、ADFSとADFS Proxyサーバファームの負荷分散を目的とした、Big-IPのLTMモジュール（英語）の展開とコンフィグレーション設定について説明します。パート2ではBig-IPのAPM（英語）（Access Policy Manager）を利用することにより、この展開作業をはるかに簡素化し、改善できることを示します。 社内ADFSサーバファームの負荷分散 前提事項および製品展開のための資料 - この展開シナリオではADFSサーバファームがインストールされ、該当するクレームプロバイダやリライングパーティとの間の信頼関係を含むコンフィグレーション設定が展開ガイド（英語）に基づいて行われていることを前提としています。また読者にはBIG-IP LTMモジュールの管理に関する一般的な知識があることを想定しています。詳細やアドバイスが必要な場合はF5のサポートサイトASKF5（英語）を参照してください。下図はADFSサーバファームの負荷をBig-IPによって分散する場合の典型的な（ただし簡略化された）プロセスフローを示しています。 クライアントがADFS対応の外部リソースへのアクセスを試みます。 クライアントはそのリソースのフェデレーションサービスにリダイレクトされます。 クライアントは社内のフェデレーションサービスにリダイレクトされます（リソースのフェデレーションサービスが信頼できるパートナーとして設定されていることが前提）。 ADFSサーバがアクティブディレクトリに対してクライアントを認証します。 ADFSサーバは、署名済みのセキュリティトークンとリソースパートナーへのクレームセットを含む認証クッキーをクライアントに提供します。 クライアントはリソースパートナーのフェデレーションサービスに接続し、そこでトークンとクレームが検証されます。該当する場合にはリソースパートナーが新しいセキュリティトークンをクライアントに提供します。 クライアントは新しい認証クッキーをそれに含まれるセキュリティトークンと共にリソースに提示してアクセスを行います。 仮想サーバとプールメンバー - 仮想サーバ（VIP）はポート443（https）を監視するよう設定されます。Big-IP SSLブリッジング（解読と再暗号化）に使用される場合、Big-IPと関連して作成されるクライアントSSLプロファイルに外部向けのSSLとそれに伴う秘密鍵をインストールしておく必要があります。ただし後に説明するように、SSLブリッジングはこのタイプの展開では好ましい手段ではありません。その代わりとしてSSLトンネリング（パススルー）が利用されます。 ADFSはTransport Layer SecurityとSecure Sockets Layer（TLS/SSL）を必要とします。したがってプールのメンバーはポート443（https）を監視するよう設定されます。 負荷分散の手法 - 「Least Connections（メンバー）」方式を使用します。 プールモニター - ADFSサービスとウェブサイト自体が応答していることを確認するため、カスタマイズしたモニターを使用することができます。このモニターはADFSフェデレーションサービスが応答していることを保証します。またこのモニターは間隔とタイムアウト設定を高めて使用します。このカスタムhttpsモニターには、サービスのステータスを確認するためドメインの証明書を必要とします。この代わりとして標準的なhttpsモニターを使用することも可能です。 パーシステンス - このADFSシナリオでは、クライアントはセキュリティトークンの要求と受領のため、ADFSサーバとの間に単一のTCP接続を確立します。したがってパーシステンス プロファイルの指定は不要です。 SSLトンネリング（この方法を推奨） - SSLトンネリングを使用した場合、暗号化されたトラフィックがクライアントからエンドポイントであるファームのメンバーに直接流れます。またSSLプロファイルは使用せず、SSL証明書をBig-IPにインストールする必要もありません。この場合にはパケット分析または変更（例：圧縮、ウェブアクセラレーション）またはその両方を必要とするBig-IPプロファイルは意味を持ちません。さらにパフォーマンスを高めるためにはFast L4仮想サーバが使用します。 ADFS Proxyサーバファームの負荷分散 前提事項および製品展開のための資料 - この展開シナリオではADFS Proxyサーバファーム（英語）がインストールされ、該当するクレームプロバイダやリライングパーティとの間の信頼関係を含め、展開ガイド(英語)に基づくコンフィグレーション設定が適宜行われていることを前提としています。また読者にはBIG-IP LTMモジュールの管理に関して一般的な知識があることを想定しています。詳細やガイドが必要な場合はF5のサポートサイトASKF5（英語）を参照してください。 先のセクションでは、社内のADFSサーバファームを対象とした負荷分散の設定を行いました。このシナリオは社内ユーザにフェデレーション化されたSSOアクセスを提供する場合に機能します。しかし社外（つまりリモート環境）にいるユーザがフェデレーション化されたリソースにアクセスしようとする場合には対応できません。この場合にはADFS Proxyサーバが役立ちます。ADFS Proxyサーバを使用することにより、社外のユーザは社内のフェデレーションに対応したリソースに加え、Microsoft Office 365などのパートナーリソースにもアクセスすることができます。 クライアントがADFS対応の社外リソースへのアクセスを試みます。 クライアントはそのリソースのフェデレーションサービスにリダイレクトされます。 クライアントは社内のフェデレーションサービスにリダイレクトされます（リソースのフェデレーションサービスが信頼できるパートナーとして設定されていることが前提）。 ADFSProxyサーバはクライアントにカスタマイズ可能なサインオンページを表示します。 ADFSProxyは承認のためエンドユーザの証明書をADFSサーバに提示します。 ADFSサーバはそのクライアントをアクティブディレクトリについて認証します。 ADFSサーバはクライアントに対し、署名済みのセキュリティトークンとリソースパートナーへのクレームセットを含む認証クッキーを（ADFSProxyサーバ経由で）クライアントに提供します。 クライアントはリソースパートナーのフェデレーションサービスに接続し、そこでトークンとクレームが検証されます。該当する場合にはリソースパートナーが新しいセキュリティトークンをクライアントに提供します。 クライアントは新しい認証クッキーをそれに含まれるセキュリティトークンと共にリソースに提示してアクセスを行います。 仮想サーバとプールメンバー - 仮想サーバ（VIP）はポート443（https）を監視するよう設定されます。Big-IP SSLブリッジング（暗号化解除と再暗号化）に使用される場合、Big-IPと関連して作成されるクライアントSSLプロファイルに、パブリック側を向いたSSLとそれに伴う秘密鍵をインストールしておく必要があります。 ADFSはTransport Layer SecurityとSecure Sockets Layer（TLS/SSL）を必要とします。したがってプールのメンバーはポート443（https）を監視するよう設定されます。 負荷分散手法 - 「Least Connections（メンバー）」方式を使用します。 プールモニター - ADFSサービスとウェブサイト自体が応答していることを確認するため、ADFSProxyプールにはカスタマイズしたモニターを関連付けます。このモニターは間隔とタイムアウト設定を高めて使用します。 「SSLトンネルを使うべきか否か」 SSLトンネリングを使用した場合、暗号化されたトラフィックがクライアントからエンドポイントであるファームのメンバーに直接流れます。またSSLプロファイルは使用せず、SSL証明書をBig-IPにインストールする必要もありません。ただしトンネリングを使用する場合、HTTP圧縮やウェブアクセラレーションなどを含む高度な最適化は行えません。クライアントの接続性やADFSサインオンページのカスタマイズなどの状況によっては、ADFSProxy展開にこのようなHTTP最適化が貢献する場合もあります。以下に2種類の選択肢（SSLトンネリングとSSLブリッジング）を比較します。 SSLトンネリング - この場合にはパケット分析または変更（例：圧縮、ウェブアクセラレーション）またはその両方を必要とするBig-IPプロファイルは意味を持ちません。さらにパフォーマンスを高めるためにはFast L4仮想サーバを使用します。SSLトンネリングを使用した場合の、Fast L4 Big-IP仮想サーバのコンフィグレーション例を下図に示します。 SSLブリッジング - SSLブリッジングを使用した場合、トラフィックは暗号化を解除され、次いでBig-IPデバイスにて再暗号化されます。これにより、接続の中のクライアントに対応する部分とプールメンバーに対応する部分の両方においてトラフィックにさらに機能を適用することが可能になります。SSLブリッジングを使用した場合の、標準的なBig-IP仮想サーバのコンフィグレーション例を下図に示します。 標準的な仮想サーバのプロファイル - ADFSProxy仮想サーバのプロファイルのリストを下表に示しています。 プロファイルのタイプ コメント パーシステンス 仮想サーバにはデフォルトのクッキーパーシステンスプロファイルを関連付け SSLクライアント パブリック側を向いたSSLとそれに伴う秘密鍵をBig-IPにインストール。 これによりBig-IPでのトラフィックのSSL終端が容易に SSLサーバ 仮想サーバにはデフォルトの「serverssl」プロファイルを関連付け プロトコル tcp-lan-optimizedプロファイルを仮想サーバのサーバ側に関連付け tcp-wan-optimized プロファイルを仮想サーバのサーバ側に関連付け OneConnect 仮想サーバにはデフォルトのoneconnectプロファイルを関連付け HTTP 仮想サーバにはデフォルトのHTTPプロファイルを関連付け HTTP圧縮 wan-optimized-compressionプロファイルを仮想サーバに関連付け ウェブアクセラレーション optimized-cachingプロファイルを仮想サーバに関連付け これでパート1は終了です。この文の草稿を読んでコメントを提供してくれた、Insightの子会社であるEnsynch（英語）のケビン ジェイムズ、デイビッド ランデル、およびルツ ミューラー ヒッパーに対し、マイクロソフトのグローバルパートナーシップを担当するF5ビジネス開発チームと共に心から感謝を捧げます。 Big-IPとADFSパート2「APM - ADFSProxyに代わる選択肢」をお楽しみにお待ちください。DevCentral の今後の方向性
DevCentral はなんと誕生 11 年を迎えます。ここまで順調に成長し、素晴らしいコミュニティが築かれたのもひとえに皆様のお陰です。当社では感謝の意を示すとともに、今後の方向性を皆様にいち早くお知らせしたいと考えています。継続的な成長を目指す当社では、メンバーの皆様からのフィードバックを参考に、当社の抱負を徐々に実現させていく予定です。今後数か月のうちに DevCentral の次の主要バージョンがお目見えします。人々を驚かすことは大好きですが、相手に関与することをコロコロ変えるのは好ましいことではありません。そのため、コンテンツを配信し、メンバーを結び付け、誰もが必要とする答えを得られるようにする当社の計画について１ つずつ説明します。 3 つのC:Clean (クリーン)、Consolidated (統合型)、Classy (高尚) 過去数年間、DevCentral にはさまざまな機能が追加されましたが、可読性や組織のインターフェイスを向上させる思い切った手段は何ら講じられませんでした。ありえません。DevCentral の長期にわたる第一の目標は、サブジェクトナビゲーションを簡便にして、パーソナライズされたコンテンツを配信することです。こうしたニーズに対応するために、デフォルトのランディングページのデザインを大幅に刷新しています。右の画像をクリックすると、当社のアイデアをご覧いただけます。以下は機能の注目すべき改良点です。 左側のページ余白に示されたトピック/テクノロジのクイックナビゲーション 中央下部にある最新の可変コンテンツの簡単なナビゲーション 右側にある最新の質問や参照頻度の高い質問の簡単なブラウズ DC を担当する当社の John Wagnon が動的コンテンツスライダを使ってそのラテン語能力を披露。これは緊急ニュースや嬉しいお知らせを配信するときに役に立ちます (Heartbleed や Shellshock、my birthday などの脆弱性を考えてみてください)。 検索の簡素化:分類法の活用 F5 が 9 回にわたって開催したグローバルアジリティカンファレンスに参加された方は、さまざまな分科会や討論会で F5 が現行および新生の業界ソリューション (コア/ハイブリッド/クラウド、セキュリティ、サービスプロバイダなど) に注力していることがおわかりになったのではないでしょうか。当社では紹介されたソリューションに着目し、注目度の高い討論を注意深く観察し、こうしたソリューションがデータ分類の適切な出発点になると考えています。ただし、コミュニティの関心を考慮して、まずはメンバーが求める事項に取り組みます。当社では、検索やコンテンツのフィルタリングを簡潔にして、質問や記事、コードの送信に要するタグ付けを軽減し、ソリューションとテクノロジという 2 つのコンテンツをメンバーの投稿の主要ピボットにします。上部に例示した高尚なホームページでは、投稿者がトピック/テクノロジのピボットから選択でき、さらに 2 つのユーザ定義タグを利用できます。これにより、私たちの多くを煩わせてきた次の事項が達成されます。 一部の投稿に伴う永遠のタグ付けが制限される (過去最多タグ数は 23 個でした。多過ぎます。) コンテンツの検索およびフィルタリングが簡便になり、どの投稿も長期にわたって参照される ユーザがどのようなコンテンツを必要とし、当社がどのようなことに重点的に取り組むべきかに関する的確な数値指標が示される F5 アジリティ D.C. で大勢の人々がこのホームページを利用し、多大な安堵感と前向きな言葉をもって迎えられました。当社は正しい方向に進んでいるものと思われます。 フィルタ、格付け、Netflix 前述のトピックナビゲーションの改良と同様に、DevCentral を探索すれば、最新の分類法を用いて迅速かつ簡単にフィルタリングし、必要に応じて結果をさらにカスタマイズできます。 答え (Q&A)、コードシェアはすべて、トピックやテクノロジを迅速にフィルタリングするロジックを共有し、先行入力のカスタムタグフィルタで結果を絞り込みます。右側の画面で、実際の画面をご確認ください。 そして、格付け……。ここ DevCentral の面々はNetflix 中毒で、私たちの場合、人生に関わる決断はすべて、私たちが見たいと Netflix が考えるものに左右されます (テレビ番組『スターゲイト SG-1』の放映権を手放したことにはイラつきますが)。Netflix などにはよく知られた評価システムがあり、当社の多くのコンテンツにも活用できるのではないかと考えています。すべての記事やコードシェア、ダウンロードにこの簡単な評価システムを導入して、現行の投票メカニズムの結果を待つまでもなく、人気のコンテンツがすぐに浮上するようにします。質問と答えには投票機能を維持しますが、1 つのスレッドに複数の人々が投稿するほうが理に適っています。Q&A について妙案があれば、ぜひお聞かせください。 今こそが未来 他にも多数の変更や改良を進めていますが、上記の内容は今後の拡張の基盤となるものです。当社では豊富な知識を有する方々がその情報を簡単に還元できるようにする一方で、その貢献をきちんと認識いたします。また、コミュニティで相談している相手が、F5 の専門担当者なのか、MVP なのか、エリートコミュニティメンバーなのかがわかるようにします。今後、楽しみな変更や有益な変化が多数実施される中、皆様のフィードバックをお待ちしています。ご提案やご質問がある場合、あるいは DevCentral のチームメンバー John Wagnon のプロファイル写真に対するコメントでも、 ここからお気軽にご連絡ください。忙しい年になりそうです。 よろしくお願いいたします。 DevCentral チーム
