Akamai Diversity

Akamai Japan ブログ

Akamai と SIEM と Cloud Security

Akamai Cloud Security ソリューションの中核ソリューションである Kona Site Defender は継続的に機能の強化・拡張を行っており ますが、API Protection のような防御の為の機能強化だけでなく、SIEMとの連携をよりシームレス且つ容易に実現することが可能な SIEM Integration という拡張機能もリリースされております。

本稿では Kona Site Defender の SIEM Integration の機能の説明を通じて、Akamai と SIEM と Cloud Security という内容について解説をさせていただきます。

API Protection にご興味がある方はこちらで解説をさせていただいておりますので是非、ご参照ください。)

 

ゼロ・レーティングとは、モバイルキャリアが従量制の通信サービスの課金対象から特定のサービス(ビデオや音楽ストリーミング等)やアプリケーションを除外(非課金化)するものです。国内ではLineモバイルがLine,Twitter等のSNSサービスを対象に「カウントフリー」を、アメリカではT-モバイルがYouTubeやNetflixなどの主要動画サービス対象に「Binge On」というゼロ・レーティングを使用したサービスを提供しています。このようなゼロ・レーティングはIoT通信を課金しない、もしくはエンドユーザーに通信料金を見えなくするような目的で、IoT(Internet of Things)分野にも適用されようとしています。アカマイを利用した場合どのようにこのゼロ・レーティングに対応できるかをご紹介します。

常時SSL化に役立つアカマイの機能

「常時SSL」(Webサイトへのアクセスを全面的にHTTPS経由にする)という言葉が聞かれるようになってから既に数年が経過していますが、いよいよ本格的にWebサイトのHTTPS化が進んできました。特にここ最近弊社への問い合わせが増えておりますが、背景としては主要ブラウザのセキュリティ強化が主な要因と考えられます。2017年初頭にリリースされたFirefox51やChrome 56からは、パスワードを送信するHTTPサイト(非HTTPSのサイト)で警告が表示されるようになっており、今後リリース予定のChrome 62からは、HTTPサイトのフォームに何らかデータを入力するとアドレスバーに警告が表示されるようなセキュリティ強化が予定されております。

HTTP Archiveによると、HTTPS経由のリクエスト数は日々増加しており、2017年6月時点で約46%(ソース: http://httparchive.org/trends.php)となっています。今後予定されているブラウザのセキュリティ強化により、これからもさらなる伸びが予想されます。
 
HTTPSへの移行はセキュリティの強化だけでなく、Webサイトの表示速度を改善できる可能性もあります。
http/2登場以前は、HTTPSへ移行することは暗号化のオーバーヘッドや通信回数の増加により応答速度が遅延する懸念がありましたが、現状ではhttp/2による応答速度の向上はもとより、更なる高速化を実現する機能であるAdvanced Accelerationや今後リリース予定のResource Optimizer(Beta)の利用も可能となります。(Ionに含まれる予定の機能です)
そこで今回は、サイト全体をHTTPS化するために役立つアカマイの機能やTipsをご紹介致します。

 

アカマイのコンテンツキャッシュ優先順位

どのコンテンツをキャッシュすべきかという記事はいくつかあるのですが、そもそもコンテンツキャッシュするためにどのような選択肢があるのかを記載します。W3C の仕様では Cach-Control ヘッダーと Expires ヘッダーの定義があり、これらのヘッダーを利用してブラウザやプロキシサーバのキャッシュを制御するのが一般的です。アカマイのような CDN (Content Delivery Network) を使う場合は、CDN でキャッシュするロジックが入るため、オリジンサーバが HTTP レスポンスで返す上記2つのヘッダーだけでなく、CDN 自身が持っている管理機構を使うことが可能です。

皆さん、こんにちは。
アカマイ・テクノロジーズ、プロダクト マーケティング マネージャの北かおりです。

このところ、弊社のImage Managerについてお問合せをいただくことが増えてきました。
これは、ウェブサイトのモバイル対応を本格的に進める企業様が増えているためだと考えています。このサイトのモバイル対応に際して、意外にやっかいな問題になるのが画像コンテンツの変換・編集ワークフローです。
その解決手段として、画像の自動最適化・配信ができるImage Managerをご検討いただくわけですが、導入・検討を進めるお客様から、「最初の設定イメージを知りたい」とのお問合せをいただくことがよくあります。
そこで少し前のエントリーですが、弊社のプリンシパル テクニカルプロジェクトマネージャRaphael Edwardsの記事から抜粋し、「レスポンシブ画像」のコンセプトと「Image Managerの設定イメージ」を簡単にご紹介したいと思います。Image Manager設定に必要なステップはわずか2つ(込み入ったケースでも3つ)です。あまりのシンプルさに驚かれるかも?

Akamai API Protection

APIマネジメント、APIエコノミーなどAPIに関連した言葉をニュースや記事として目にする機会が増えています。Akamaiでも日々Webサイト、動画等々いろいろな種類のトラフィックを配信していますが、APIを利用したトラフィックは非常に大きな割合を占めるようになってきています。現在、Akamai経由で配信しているFQDNのうち約4%でAPIを取り扱っているのですが、実トラフィック量に占める割合は約20%程度となっております。

APIは多くの場合JSONなどのテキストデータになりますので、1リクエストあたりのデータ量は画像等と比べた場合は小さくなりますので、非常に多くのデータが流れていることが想像いただけると思います。

このような中でAkamaiでは重要度を増すAPIのトラフィックに対するユーザ体験を向上させるために大きく以下の5つの機能を提供しています。

  • API Acceleration - 従来から持っているWebの高速化機能をAPIにも適用することにより、APIトラフィックデータをより高速に運ぶ機能の提供
  • API Caching - こちらも従来から持っているWebのキャッシュ機能をAPIにも適用することにより、サーバの負荷低減と高速化を実現
  • API Compression - APIのデータを圧縮しデータサイズを60-90%削減することでAPIトラフィックデータをより高速に運ぶ機能の提供
  • API Prioritization Cloudlet - サーバが高負荷になった場合などに優先度の高いAPIトラフィックをサーバに透過させたり、優先度の低いAPIトラフィックに対して代替レスポンスの実施など行う機能の提供(こちらはCloudletというコンポーネントで提供しています。CloudletについてはBlogサイトをご参照下さい
  • API Protection - JSONやXMLデータのインスペクトやHTTPメソッドの確認、APIリクエストに対するDDoS/流量過多を防ぐためのRate Controlの提供

今回の記事ではKona Site Defenderの新機能であるAPI Protectionについてご紹介いたします。

UDPとTCP

データの大容量化や、モバイルでのインターネットの閲覧の普及により、より良い品質での通信が求められるようになって来ています。 現在、Webの世界で広く用いられているTCPプロトコルは、厳格な通信プロトコルで、通信環境の悪い所でも、再送制御や輻輳制御を実装する事で、信頼性の高い通信を維持する事が可能です。

TCPでは、"スリーウェイハンドシェイク"で送信、受信側のセッションを確立させた後、データパケットの送受信をACKパケットで確認しながら、データが届かない時はデータを再送信する等の制御を行い確実にデータを届けるプロトコルです。

また、一度に送るデータサイズは、小さなデータよりも大きなデータの方が、送受信の制御パケットの数が少なくできるため、転送効率が良くなります。そのため、TCPでは、送信データサイズを、確実に送信できそうな小さなデータからはじめて(スロースタート)、様子をみながら一度に送るサイズ(ウィンドウサイズ)を少しづつ大きくし、転送効率を上げていくなどの制御が行われています。

一方で、一度に大量のデータを送りすぎると、回線が混雑(輻輳)してしまうため、パケットのロスが起きた時は、一旦ウィンドウサイズを小さくするなどの制御も同時に行われ、データを安全、確実に届けるための様々な工夫が実装されています。 udpvstcp.jpg

TCPは非常に良く考えられたプロトコルですが、このような送信側と受信側のきめ細かなやりとりは、やりとりがきめ細やかな分、距離や回線の品質によりネットワークの遅延が大きい時は、データの送受信にかかる時間に大きな影響をもたらす事になります。

TCPの後に開発されたUDPは、音声や動画通信に向けて、低遅延を目指した設計がされています。TCPで実装されていた細かな送受信制御はそぎ落とされており、パケットロスなどデータの到達性については保証されていません。 UDPは、そのようなデータロスが本質的に大きな影響を及ぼさないIP電話やビデオ電話の世界で広く用いられています。

第2回は、キャッシュに関するベストプラクティスについてご紹介しました。
第3回では、キャッシュ対象外のコンテンツにも効果のある、Akamaiによる通信高速化について、お話します。

「遅延」がWebパフォーマンスのボトルネックになることは、第1回で述べました。
 
bestpractice_web_perfromance01_001.png
キャッシュを利用しない場合でも、Akamai経由で通信することで「遅延」の影響を小さくすることが可能です。
  1. TCPコネクション/TLSセッション確立の時間を短縮
  2. TCP最適化による高速通信
  3. 次にリクエストされるコンテンツの先読み
  4. 最適な経路選択により、ネットワーク経路上の混雑を回避

現在のWebサーバーへのアクセスは、非常に多岐に渡るエンドユーザー環境からのアクセスを受けます。そのため、それぞれのエンドユーザー環境に応じたコンテンツ配信が必要となり、その最適化はWebサーバーのコンテンツ提供者にとっては、非常に大きな負担となっています。その上、ユーザー要求、新たな技術、脆弱性などが次々に現れ、日々の業務に併せて、それらの対応もままならない状況になっているWebサーバー管理者の皆様もいらっしゃるのではないでしょうか。今回は、HTTP/2関連技術を用いて、簡単にWebサーバーのパフォーマンスの最適化を行える、Akamaiの最新のソリューションをご紹介したいと思います。

Akamaiを介して配信をすると、簡単にHTTP/2によるコンテンツ配信を実現することができます。

HTTP_2.png

2017年1月24日にアカマイはEnterprise Application Access (EAA)という製品を発表しました。

この製品は今までのアカマイのウェブサイトに対する高速化やセキュリティのソリューションとは一線を画し、エンタープライズのネットワークに向けたソリューションとなります。外部に公開されたウェブアプリケーションではなく、社内アプリケーションが対象となり、それに対するリモートアクセスのソリューションとなります。

このブログでは、リモートアクセスにおける課題と、EAAがどのような価値を提供できるかについて解説させて頂きます。

エンタープライズの社内アプリケーションは、データセンターもしくはAWSやAzureといったクラウド上に置かれています。そしてそのような社内アプリケーションや内部ネットワークに外部(特にインターネット)から接続させないため、ファイアウォールが設置されています。ファイアウォールはコンセプトとしては全てのインバウンド(外部から内部への)コネクションを遮断し、アウトバウンド(内部から外部への)コネクションを許可します。内部ネットワークにいるユーザがその社内アプリケーションにアクセスするのは簡単で、単純に直接アクセスしてアプリケーションを使うだけです。

ただ、リモートユーザのアクセスとなると簡単にはいきません。
ファイアウォールはインバウンドコネクションを遮断してしまいますので、特別な考慮が必要になってきます。
ntakahas-eaa-1.png

1 2 3 4 5 6 7 8 9