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
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
ネットワークインフラは、イミュータブルなものになれるのか？
Please find the English language post, by Lori MacVittie, from which this was adapted here. イミュータブルインフラストラクチャ、私は使い捨て可能なインフラストラ チャと呼んだ方がふさわしいと思うのですが、この1年でDockerとコンテナ化技 術の成功によって再び注目を浴びました。また、DevOpsは、自動化と関連する 使い捨て可能なインフラストラクチャの概念と、取得から構成までのすべてを 自動化して、アプリケーションデータパスのあらゆるものを提供する「テンプ レート」の使用を復活させるうえで役割を果たしてきました。 技術トレンドが、昨今のビジネスの核であるアプリケーション開発から、アプ リケーションデータパスの終点であるネットワークに必然的に移行しているた め、ネットワーク インフラストラクチャがイミュータブル(”不変”)である かどうかを考えるのは当然のことです。結局、SDNのようなトレンドによって、 まったく反対の方向、つまり、変わりやすく、非常に活力的な方向に進むこと が目標であることがわかるため、ネットワークのあらゆるものに不変性を適用 することは直感に反することのように思えます。 この問題に答える前に、イミュータブルインフラストラクチャが何を意味する のかについてちょっと考えてみる(場合によっては、再考する)必要があります。 シェフのジュリアン・ダン氏が書いたブログ「イミュータブル インフラストラ クチャ:実用的であるかないか?」を引用しながらお答えします。 イミュータブルインフラストラクチャは一般的に、一度構築し(仮想マシンの イメージ、コンテナのイメージなど)、1つまたは多数のインスタンスを実行し たら、再び変更することはないスタックとして定義されています。開発モデル は、インスタンス/コンテナを終了した後、新しいイメージを構築して、古いイ ンスタンスを捨てるという最初の手順をもう一度やり直すことです。 しかし、なぜそんなことをするのか疑問に思っているかもしれません。よく考 えれば、実際には、時間による変化によって発生した乱雑さが原因だとわかる でしょう。 理由は、エントロピーです。 ソフトウェアエントロピーの法則は、イヴァー・ヤコブソン氏およびその他によ る著書『オブジェクト指向ソフトウェア工学:Use Caseによるアプローチ』で説 明されています。 熱力学の第2法則には、原則として、断熱系の乱雑さは減少することはなく、変 化しないか、増大するだけであると記述されています。この乱雑さの基準がエ ントロピーです。システムを変更すると、その乱雑さ、つまりエントロピーは 常に増大するとされているため、この法則は、ソフトウェアシステムに対して 妥当だとも思えます。これは、ソフトウェアエントロピーとして知られてい ます。 この法則は、ファームウェアまたはシステムレベルの更新を適用しなければな らないシステムに対しても当てはまります。システムには、ホットフィックス やパッチが導入されます。また、緊急の構成変更が必要な場合でも、理想の世 界では、厳密に守られた変更管理プロセスを通してのみ変更しなくてはなりま せん。イミュータブル(使い捨て可能な)インフラストラクチャが解決しよう としている問題は、システムに導入する変更が多いほど、より乱雑になり、不 安定さが増すように見えることです。乱雑で、無秩序なエントロピーです。 それでは、使い捨て可能なインフラストラクチャの概念を考えてみましょう。 稼働中のシステムを変更しないという前提に基づくと、使い捨て可能なインフ ラストラクチャは、パッチやアップグレードとして構成を変更する必要がある 場合、新しいイメージを構築して、既存のものを展開する際に最初に使用した 同じプロセスでそれを展開する必要があると言われています。 そして、古いものを破棄します。 いったいなぜ、そんなことをするのでしょう。 既知のプロセスに従って、インフラストラクチャを作成して展開することが前 提なので、ボブが手動で/etc/resolv.confを編集したかどうかや、外部から新 しいライブラリを追加したかどうかを気にする必要はありません。ボブがそれ を行ったとしても、展開プロセスのコンテキスト内で行っているので、それは インフラストラクチャの既知の状態に含まれています。 これは、インフラストラクチャの外在的な既知の状態を維持するという重要な 概念です。聞き覚えがある場合は、それがSDNの概念とデータプレーンからの制 御の分離と密接な関係があり、ネットワーク全体の状態がわかる集中型のコマ ンドと制御モデルを作り上げているからです。ネットワーク内の個々のノード を変更することはないため、ノードが複雑になることや、アリスがある晩遅く に問題を修正するために追加したルートについて心配する必要はありません。 すべてはネットワークのコントローラで監視されています。 チャド・ファウラ氏は、この概念を「サーバを捨て、コードを焼き付けろ:イ ミュータブル インフラストラクチャとディスポーザブルコンポーネント」でう まく説明しています。 システムが自動で作成され、作成されたときからまったく変更されていないこ とが明らかである場合には、これまでに述べてきた問題の大部分は該当しませ ん。アップグレードする必要がありますか。問題ありません。新しい、アップ グレードされたシステムを構築し、古いシステムを破棄しましょう。新しいバー ジョンのアプリが必要ですか。同じことです。新しいバージョンのサーバ(ま たはイメージ)を構築し、古いものを破棄しましょう。 では、目の前にある問題、つまりネットワークインフラストラクチャはイミュー タブル(使い捨て可能な)インフラストラクチャになり得るか、という問題に 戻ります。 答えは、なり得ます。 次に、海外の有名な‘難しい’クイズ番組「64,000ドルの質問」レベルの最高 難度の問題です。このような使い捨て可能なネットワークインフラストラク チャを、仮想化またはコンテナ化する必要があるでしょうか。 これはちょっと難しい問題です。このようなインフラストラクチャが、大規模 なシステムの一部ではなく、それ自体を展開し破棄できる自己完結型のエン ティティであると仮定した場合、答えはイエスです。逆に巨大ネットワーク上 のサービスの構成ファイルを集めたものを使い捨て可能なインフラストラク チャと呼ぶことはできません。なぜなら、それは使い捨てではない大規模なシ ステムの一部であるからです。インフラストラクチャは自己完結型でなければ ならず、真に使い捨て可能なエンドツーエンドのアプリケーションインフラス トラクチャが求められているのなら、仮想化またはコンテナ化されたソフト ウェアが最適です。 考えなければならない理由 ネットワークインフラストラクチャがイミュータブルかそうでないかを考える 理由は、インフラストラクチャとアプリが近いほど、つまりインフラストラク チャとアプリとの親和性が高いほど、そのインフラストラクチャコンポーネン トを変更した場合にアプリに影響を与える可能性が高くなるということです。 たとえば、負荷分散によってアプリケーションの動作が大きく変わることがあ ります。負荷分散サービスのパッチやアップグレードがアプリに影響を与える 可能性があります。同様に、HTTPベース攻撃を検知して停止させるスクリプト やパフォーマンスを向上させるTCP最適化など、上流サービスは問題に対応する ために外部チャネルで最初に「微調整」されることがよくあります。そのため、 相対的にさらに上流に位置するサービスよりも、エントロピーの悪影響を受け やすくなります。 したがって、アプリ(計算)インフラストラクチャを使い捨てにしようと考え る理由は、上流のインフラストラクチャサービスにも当てはまります。(アプリ ケーションサービス インフラストラクチャを含む)アプリケーションアーキテ クチャスタック全体でのエントロピーの悪影響を抑制するためです。 これはロードバランサを、ネットワークに挿入したハードウェアブリックのペ アとして考えるのを止め、仮想化されているかソフトウェアをベースとする、 クラスタ化の進んだ、アプリごとの、サービスベースのアプローチについての 検討が始められた理由の1つです。このようなアプリケーションサービスの仮想 化/ソフトウェアインスタンスの使い捨てはさらに簡単であり、外在的で自動化 されたプロセスのプロビジョニング、および使い捨て可能なインフラストラク チャアプローチを可能にする展開に適合しやすくなります。 そうすると、これを実用的インフラストラクチャのように、つまりSDNによって 実現されるもののように考えるかもしれません。「v1」の破棄を無視してまった く新しい「v2」を選択した場合、基本的には同じことになります。この場合、 問題は破棄の追加手順によってインフラストラクチャエントロピーが抑制され るかどうかということになります。また、これは利用しているインフラストラ クチャで実際に行われた変更の量に応じて、自分だけが答えを出せる質問でも あります。前提は、変更の量が多いほど、エントロピーも増大するということ です。これまでの変更量によって答えは変わります。 要約すると、ネットワークインフラストラクチャは使い捨て可能(イミュータ ブル)にすることができ、アプリケーションのアプリケーションサービスとの 親和性が高いほど、そのようなインフラストラクチャが使い捨て可能であるこ とから恩恵を受ける可能性が高くなります。DevOpsを採用してアプリケーショ ンインフラストラクチャを実用化している場合は、自分で認識していようとい まいと、使い捨て可能なアプローチに移行中である可能性が高くなります。 では、完全に使い捨て可能なインフラストラクチャを完成させることはできる でしょうか。現実的には問題が発生する可能性があるため、おそらくできませ ん。しかし、本格展開、アップグレード、および計画された変更を管理する方 法から考えて、最終的にアプリケーションインフラストラクチャの一部を使い 捨て可能にすることは十分に可能です。 最終更新日:2015年2月23日Agility 2015テクニカル講座「APM実践応用編」課題１の回答 （APMでグループごとに接続元のアクセス制御する方法）
今回から複数回に渡り、2015年2月25日に行われたF5のイベントAgility 2015の中のテクニカル講座「APM実践応用編」の最後に出題されたAPMの5つの課題の回答について順番に紹介させていただきます。 回答は2015年5月15日で締め切りとさせていただき、正解者には粗品ながらプレゼントをお送りさせていただきました。お忙しいところのご参加ありがとうございました。 今回は課題1の「グループごとに接続元のアクセス制御」を行う方法について詳しく紹介いたします。具体的な利用シーン、利用例として、下記のようなケースが考えられるときに役に立つソリューションです。 課題1 グループごとに接続元のアクセス制御 あるお客様で、LDAP Attributeの特定のグループ “MyGroup” に属するユーザーのアクセスは特定のネットワークアドレス 10.24.0.0/12 からのみ許可したい。 グループ属性情報は session.ldap.last.attr.grp = “MyGroup” のセッション変数に書かれている。 これを実現するVPEアクセスポリシーを作成せよ。 これは、下記のような課題を抱えるお客様に実際に役立つソリューションとなります。 「イントラネット上のWebアプリケーションへのアクセス環境の提供に、APMを社外からのリモートアクセスだけでなく社内からのアクセスにも利用することを検討している。社内環境は社員と契約社員、外部の常駐員など、グループに応じてアクセスの制御を行うが、特定のITグループのメンバーは社外から接続することはあり得ないので、イントラネットの10.24.0.0/12のネットワークからの接続のみを許可したい」 回答例 まず、10.24.0.0/12からのアクセスのみ、という部分それ自体がトラップになっています。実際には10.24.0.0/12という表現は不適切で、10.16.0.0/12と解釈して10.24.0.0を含む10.16.0.0-10.31.255.254からのみアクセス許可するのか、それとも10.24.0.0/13と解釈して10.24.0.0-10.31.255.254からのみアクセス許可するのか、最初にお客様にこのあたりを最初にご理解いただいた上で正しい要件を確認し直すのが確実です。ここでは、お客様がサブネットマスクの指定をどこかで誤っており、10.24.0.0-10.31.255.254からのアクセスのみを許可したいという意図だったため、10.24.0.0/13が正しい要件だったとします。 次に、社内からのアクセスで利用するVirtual Serverに対し、Source Addressで10.24.0.0/13からのみを許可すれば良い、と安易に考えるケースもあるかも知れません。こうすると10.24.0.0/13以外からのアクセスを認めるために別のVirtual Serverを用意したり、Virtual Server毎に異なるAccess Profileを設定しなければならなくなるなどの問題が出てきます。ネットワーク環境によってはWAN側とLAN側で別のVirtual Serverを立てられないケースも出てくるため、安易にグループ対応のアクセス制御を目的にしたVirtual Serverを複数立てていくのは、ほぼナンセンスとなります。 Logon Pageで入力された資格情報を使用してLDAP Authとした後にLDAP Queryでグループ情報を取得するという流れになりますが、認証を通った後は A) MyGroupで、かつIPアドレスが10.24.0.0/13の場合 B) MyGroupでない場合 のいずれもアクセス許可としたいため、ここではマクロを新しく作ります。マクロを作ることでマクロのOutは複数個設定可能で、上記のA)、B)いずれの場合もOK、それ以外の C) MyGroupで、かつIPアドレスが10.24.0.0/13以外の場合 はNGとします。 こうすることで、分岐を増やすことなく同じAdvanced Resource Assignを共有できるメリットもありますが、仮にMyGroupの場合は割り当てるACLも異なる場合は上記の例ですとマクロのMyGroupIPChkの中で合わせてACLを割り当てておくと良いでしょう。 session.ldap.last.attr.grp = “MyGroup” を満たした場合にのみ追加のチェックを行うためのIsIPOKの部分は[Empty]から作成します。[Empty]アイテムを追加し、クライアントのIPアドレスが入ってくるAPMのセッション変数session.user.clientipをチェックするという形になります。 のようにEmptyを追加してから、今回は10.24.0.0/13なので8つしかないためOR構文で複数条件を接続して のような形で記述するのも一つの方法です。この場合は8つで済むためまだ楽ですが、数十、数百の条件をORで接続するのはエレガントではないほか、この条件文に記述できる長さにも制限がありますので、汎用的なものとしては のようにcidrAddrにCIDR形式のネットワークアドレス/マスクを記述する形にするのも一つの方法です。
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リファレンス アーキテクチャ サイトをご覧ください。グローバル金融機関向けのF5 DDoSリファレンス アーキテクチャ
今回投稿したブログは、F5ネットワークスのテクノロジー・エバンジェリストであるDavid Holmesのブログ投稿「The F5 DDoS Reference Architecture - Global FSI Edition」を元に、日本向けに再構成したものです。以下は、David Holmesの個人的体験談に基づいています。 皆さんは、ジョージ・クルーニー主演の「マイレージ、マイライフ（原題：Up in the Air）」という映画を観たことがあるでしょうか。1000万マイル（航空会社のマイレージ、しかも国内線だけで）達成を人生の目標にしていた男の物語です。この映画の中で主人公が「年間35万マイルも飛んでいるんだ」と語っていたことを思い出します。月までの距離が約20万マイルですから、彼はそこからさらに15万マイルも彼方へ、年間で移動していたことになります。私（David Holmes）はこの映画が大好きです。なぜなら私も同じような状況に置かれており、実は私もこの2年余りの間に、30万マイル近くを空の上で過ごしてきました。 空の上で書き上げた2段構成のアーキテクチャ 私の旅のほとんどは、著名なグローバル金融機関への訪問であり、用件はDDoS攻撃に対する彼らのチャレンジに関するものです。この取り組みがもたらした大きな成果のひとつが「F5 DDoSリファレンス アーキテクチャ（F5 DDoS Reference Architecture）」です。このアーキテクチャは、ボリュメトリック型と非対称形の両方のDDoS攻撃を防御するために最適化された、分割型のネットワーク アーキテクチャです。すでにこのアーキテクチャを実現している金融機関もあれば、構築中の金融機関、あるいは早急に構築したいと希望している金融機関もあります。 私はこのアーキテクチャに関するドキュメントを、すべて飛行機の中で書き上げ、新しい「F5 reference architecture site」に掲載しました。飛行機の中では、美人アテンダントに時折気を散らされる以外は、集中して物書きができるからです。 このアーキテクチャの本質として、DDoS攻撃に対する防御機能を2段構成にしている点が挙げられます。 第1段：ネットワーク防御 第1段の防御は、ネットワーク ファイアウォールの近くに実装します。この防御機能は、SYNフラッドやICMPフラッドといった攻撃を緩和するよう設計されている他、アクセス回線の帯域使用率が80～90％になる程度のボリュメトリック攻撃にも対応します。多くの金融機関は独自のIPレピュテーション データベース（パケットを送ってきたソースIPアドレスが信用できるか否かを識別するためのデータベース）を構築しており、DDoS攻撃を受けた際にはその情報に基づいて、ソースIPアドレスからのパケットを制御します。 このリファレンス アーキテクチャは、ネットワーク ファイアウォールがF5製品か否かを問わない内容になっています。しかしあえて言わせていただければ、F5製品ほどDDoS攻撃防御を強く意識したファイアウォールは、他に存在しません。 第2段：アプリケーション防御 第2段は、CPU負荷の大きい防御メカニズムであり、アプリケーションを意識した上で展開すべきと、F5が提唱しているものです。この種のメカニズムとしては、ログイン ウォールやWebアプリケーション ファイアウォール ポリシー、F5 iRulesを活用したダイナミック セキュリティ コンテキストがあります。またSSLの終端も、この第2段に含まれます。第２段において、特定機能に特化した専用のIDS/IPSデバイスを採用した場合には、かなりのラックスペースが専有される可能性があります。 どこでSSLを終端させるべきか このリファレンス アーキテクチャを発表した後、「第2段ではなく第1段でSSLを終端させることは可能だろうか」という質問を複数の方々からいただきました。答えは「Yes」であり、私たちのお客様の中にもそのようなケースは存在します。しかしこれらのお客様はグローバルな金融機関ではありません。グローバルな金融機関はできる限り、彼らの暗号鍵を最前線のファイアウォールの後ろに隠そうとしています。彼らの資産はインターネットの中で最も高い価値を持つ攻撃ターゲットであり、SSLの暗号鍵はその最たるものだと言えるからです。 このアーキテクチャに関する詳細は「F5 Synthesis reference architecture site」で解説しています。またこのサイトにはDDoS攻撃防御だけではなく、クラウド化やLTEローミング、サービス プロバイダー向けセキュリティなどの解説も掲載されています。 このリファレンス アーキテクチャに対する反応はポジティブなものでした。お客様はぜひとも、技術的な詳細を知りたいと言ってくださったのです。飛行機の中での執筆作業は、ジョージ・クルーニーが過ごした時間よりも、間違いなく意義のあるものでした。ところで今ふと思い出したのですが、ジョージ・クルーニー主演映画の中で私が一番気に入っているのは「ラスト・ターゲット（原題：The American）」です。ぜひご覧になってください。このDDoSリファレンス アーキテクチャを読み終える間に、ネットからストリーミングできるはずですから。ハイブリッド環境が要求する“よりスマートな”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の役割を深く理解し、積極的に活用することが求められています。企業アプリケーションでも進むクラウドへの移行
かつてアプリケーションは、単一のインフラストラクチャ上で集中的に管理されており、データセンター内では、外部ネットワークとの境界にいくつかのセキュリティ機能を配置することで保護されていました。IT部門の役割は、データセンター内で稼働するアプリケーションの可用性やパフォーマンス、セキュリティを確保することであり、アプリケーションのライフサイクル全てを管理することが可能でした。 しかし、このような、データセンターで全てが管理できるというような状況は、すでに過去のものだといえます。現在では、多くのアプリケーションにおいて、プライベートクラウドやパブリック クラウドへの移行が進んでいます。CIOは管理性と引き換えに、俊敏性とコスト削減を可能にするクラウドベースのモデルを選択しつつあります。 多くの業務アプリケーションは、すでにクラウドへと移行しており、SaaSの利用も広がっています。また、IaaSモデルを採用したモバイル アプリケーションの活用も拡大しています。このような多様な環境において、今日のIT部門は、アプリケーションの可用性やパフォーマンス、セキュリティを保証しなければならないのです。高いサービスレベルが求められるのは、ミッションクリティカルなアプリケーションだけではありません。例えば、消費者向けのアプリケーションでは、ダウンロード回数やエンゲージメント率が重視される傾向にありますが、これらにおいても、高い可用性とパフォーマンス、セキュリティが求められます。 このような状況に適切に対処するために、全てのアプリケーションには“アプリケーション中心の戦略”が必要と言われています。そして、この戦略を具現化するためには、アプリケーションが展開されている場所にかかわらず、適切なアプリケーションサービス（L4-L7サービス）が不可欠となります。 アプリケーション中心の戦略とは それでは、アプリケーション中心の戦略とは、具体的にどのようなものなのでしょうか。それは、アプリケーションの展開モデル（デプロイ方法や場所等）にかかわらず、全てのアプリケーションに一貫したサービス提供を保証する戦略です。 クラウドへの移行は、初期投資や運営コストの削減を可能にしますが、いわゆる“クラウドファースト戦略”だけでは十分ではありません。クラウドに移行してコストを削減できたとしても、パフォーマンスや可用性が低下してしまえば生産性は低下し、大きな損失を招く危険性があるからです。クラウドへの移行は、IT部門のビジネスモデルやネットワーク アーキテクチャ、アプリケーションの展開手法、ハードウェアやソフトウェアの選択など、企業ITにかかわる様々な側面を否応なく変化させています。しかし、アプリケーションが重要であるということは、依然として変わりません。「常に適切な状態でアプリケーションが利用できること」を最優先にする戦略が、アプリケーション中心の戦略なのです。 また、クラウド移行によって複雑化した環境においては、これまで培ってきたスキルやポリシーの継続的な利用を可能にすることも重要です。企業のIT部門にとって、これらは大切な資産だからです。さらに今後は、DevOpsによる継続的な開発・展開・運用の実現も求められます。アプリケーション中心の戦略は、このような要求にも応えなければなりません。 クラウド時代において、アプリケーション中心の戦略を適合させるためには、アプリケーション サービスも進化する必要があります。オンプレミス、クラウド、SaaSのいずれの環境においても、アプリケーションの可用性やパフォーマンス、セキュリティを保証できる仕組みが必要なのです。そして、これらを一貫して展開し、管理することも求められます。 アプリケーション中心の戦略を成功に導くには F5はこのような要件に応えるとともに、クラウド時代におけるアプリケーション中心の戦略を成功に導くため、イノベーションを継続的に推進し、製品の拡張に取り組んできました。この取り組みの中核には、BIG-IPによる配信/セキュリティサービス機能と、BIG-IQが持つ管理/オーケストレーション機能の強化があります。取り組みの結果、F5は、アプリケーション中心の戦略をさらに強力にサポートする新機能を盛り込んだ、BIG-IP 12.0のリリースに至りました。 BIG-IP 12.0は、SSL Everywhere、拡張された不正防止機能、Office 365などブラウザを使用しない環境もサポートする最先端のSAML強化をはじめとしたSSO（シングル サインオン）の改善、ECC（楕円曲線暗号）やFS（フォワード セキュリティ）、Camelliaといった新たな暗号のサポートによるプライバシー保護とメッセージ改ざん防止の強化など、アプリケーション セキュリティのための最新の手段を提供しています。また、キャッシュ拡張、HTTP/2への対応、そしてハイパースケールなDNSによって、コストのかかるアプリケーション改修を行うことなく、多様な環境におけるパフォーマンス向上も可能にしています。 オンプレミスやプライベート クラウド、パブリック クラウド、さらにはSDNにも対応するため、F5はBIG-IQとBIG-IPによるオーケストレーションと管理機能の拡張も継続しています。これまでにも、F5は、Cisco ACI、VMware NSX、OpenStack、VMware vCloud Air、Amazon Web Servicesをカバーしたエコシステムを作り上げてきましたが、今回さらにMicrosoft Azureが加わりました。また、クラウドやDevOpsへの取り組みを支えるため、仮想化された軽量の負荷分散ソフトウェアであるLineRate Pointを含めた幅広いソフトウェアもすでに提供していますが、これらを補完する拡張されたプログラミング ツールも新たに提供しています。DevOpsのプロセスを自動化していくためには、APIとデータ パス スクリプトが必要になりますが、この要求に対応するためF5は、iRulesエディターと拡張されたiControl APIの提供も開始しています。 ここでは紹介しきれませんでしたが、F5は製品の改善と強化、機能の追加を積極的に進めています。これらの取り組みを通じてF5は、企業のIT部門がアプリケーション中心の戦略に基づき、アプリケーションの開発から展開、運用に至るまでを、クラウドへと拡大し続けることを支援します。
御社の『全ての』 業務アプリケーション、可用性、高速化、セキュリティを担保されていますか？意外に知られていない、企業インフラのアプリケーション環境の課題に対するF5 の回答とは?
BYOD（個人端末の業務利用）などの追い風に後押しされたスマートデバイスの普及やインターネット通信量の激増により、通信インフラは激変の真っ只中にあります。市場調査会社のフロスト＆サリバン社は、モノのインターネット(Internet Of Things, IoT)において、接続されるデバイスの数は、2020年までに世界で800億台に達すると予測しています。 また、モルガン・スタンレーの推計によると、一般的ないち企業に運用されているアプリケーションの数は、平均で1,000にも上るとされています。自社ビジネスがアプリケーションに依存すればするほど、それらのアプリケーションがセキュアであること、「落ちない」こと（いわゆる高可用性）、そして遅延知らずで安定した高速なアクセス環境であること、、、そんな要求は当然のものとなります。また、ネットワーク層を主に狙ったものから、徐々により高度なアプリケーションレイヤを狙うものへと進化しているDDoS攻撃を始め、サイバー攻撃の手口はさらに巧妙化してきています。 しかし、アプリケーションが増えれば増えるほど、そして環境が高度化複雑化すればするほど、全てのアプリケーションに必ずこれらのセキュリティ、可用性、高速化などの基盤を漏れ無く提供することは困難になります。結果、事実として、優先度の高いクリティカルなアプリケーションから順にこのような基盤を展開していき、不本意ながらも一部のアプリケーションは脆弱な基盤の上で運用するーアプリケーションがビジネスに与える影響が日増しに大きくなってきているにもかかわらず、そんな決定を下す必要がある企業インフラの現場は非常に多いのです。 一方、ITインフラにおける劇的な環境の変化によりデータセンタ内のアプリケーション運用・管理の現場のニーズも変わってきています。クラウド、モビリティ、セキュリティなどの重要度が増し、いつでも、どのような環境においても、誰に対しても、アプリケーションを確実に提供することが今まで以上に求められているからです。そしてビジネス、コンシューマ利用を問わず、インターネットやネットワーク接続を前提としたデバイスへの依存度が高まっていることが更にこの動きに拍車をかけています。 このように変化するニーズに対して、Software Defined Networking (SDN)のような「ソフトウェアというアプローチでネットワークの構築・運用を行う」テクノロジーが出現してきています。ネットワークを利用したサービスが多様化する中、ITインフラの運用の現場では、当然新しいアプリケーションやサービスを展開・変更する、という機会が劇的に増えています。そのような中、アプリケーション自体が素早く開発してサービスインできるとしても、それを支えるインフラが素早く準備できなければそれ自体がビジネスの足かせとなってしまいます。この問題を解決するため、SDNのような技術が注目され、ソフトウェアの視点の（まさにソフトウェア定義の）運用が期待されています。 さて、ここまでのSDNについては、一般的に議論されており、ご存じの方も多いかと思います。 ところが、現在のSDNの議論において、盤石なL2L3レイヤの構築や標準化に話題が集中する一方、L4L7、いわゆるアプリケーションレイヤの議論には至らない傾向があるようです。 アプリケーションが落ちることなく、高い可用性を保ち、且つセキュアであり続けるにはこのレイヤの技術（L4-L7トラフィック処理）をしっかり検討・設計する事が不可欠です。F5は自身のソリューション群を、L2-L3におけるSDNのアプローチをL4-L7（のアプリケーションレイヤ）に応用し、かつあらゆるL2-L3基盤のSDN技術や従来型のネットワーク技術にシームレスに対応する「Software Defined Application Services」と位置付けました。これは、アプリケーションそのもの、L2-L3ネットワーク技術、L4-L7アプリケーション配信技術を一体化させ、アプリケーションモビリティ、セキュリティ、アクセス管理やユーザアイデンティティ管理、パフォーマンスと可用性といった課題に対するソリューションです。 「Software Defined Application Services」の主な特徴として、ハードウェアアプライアンスや仮想アプライアンス、外部クラウドなどのあらゆる環境上でシームレスに同じ機能、ソリューションを透過的に提供できる点があげられます。これにより、自社のインフラやデータセンタだけでなく、プライベート、パブリック、ハイブリッドなど様々なクラウド環境すら活用したスケーラビリティ（拡張性）を実現し、ビジネス環境がどのように変化しても柔軟にインフラが変幻自在に対応できるーそんなユーザ環境、アプリケーション環境を構築する事が可能となります。 重要なのは、「Software Defined Application Services」は、ただ単に次世代のL2-L3インフラ技術の上で安定した可用性・高速性・セキュリティを提供するだけでは無いという点です。冒頭でご紹介したような「優先度の高いアプリケーション」に限らない、全てのアプリケーションに必要とされている技術を無限の拡張性により提供する事ができるのです。自社のサービスの重要度を天秤にかけ、どのアプリケーションにより良いインフラのリソースを割り当てようか、と悩む必要がなくなるーF5はそんな世界を目指してソリューションを提供してまいります。
