Akamai Diversity

Akamai Japan ブログ

Akamai API Gateway のご紹介

はじめに

Akamai Intelligent Platformは全世界中の15-30%のインターネットトラフィックを配信する中で、非常に多くのAPIを利用したトラフィックを観測しています。2018年現在、1日あたりのヒット数は445 Billion、データ量にして2.4 PetabyteものAPIトラフィックが配信されており、前年と比較した増加率(YoY)はそれぞれ+35%、+45%におよびます。

これまでAkamaiはAPIトラフィックに対し、高速化機能(SureRoute、GZIPデータ圧縮、HTTP2等)や、CacheによるAPIオリジンのオフロード、API Protectionによるセキュリティ機能を提供してきました。

2018年にリリースされたAkamai API Gateway(以降、AAG)の拡充により、従来機能に加えて、API認証/認可機能、リクエスト数制限、高度なCache機能を提供することが可能になり、世界最大規模且つ高信頼なAkamai Intelligent Platform上で包括的なAPIトラフィックのマネジメントの実現が可能になりました。

msuzuki_aag_01_update2.png

本ブログではAAGにフォーカスを当てたいと思います。

 

インターネットの発達およびそれに関わる技術の進歩により、インターネットを活用したサービスが増え、便利な一方でセキュリティインシデントも後を絶ちません。ニュースなどで一般に公開されているセキュリティインシデントは「氷山の一角だ」なんて事もよく耳にされるかと思います。

今回はWebセキュリティに関して、攻撃をする側の視点を交えてサービスを提供する側と利用する側のセキュリティについて考えてみたいと思います。
まずはWebにおける攻撃対象となり得る領域(Attack Surface)と攻撃をする側はどんなことをしているのか簡単に触れていきます。

Webにおける攻撃対象となり得る領域(Attack Surface)

単純にWebに対する攻撃と言っても、様々な種類の手法がありそれぞれの手法で悪用する箇所は異なります。Webサービスでは大きく以下の4つが攻撃対象となり得る領域になります。
1) Webサーバー
2) アプリケーションロジック
3) データベース
4) ブラウザ (クライアント)

WebApplication_workflow_v3.png

図1. WebApplication実行の流れと攻撃対象となり得る領域

攻撃をする際のフェーズ

攻撃側にとっては情報収集をして実際に攻撃をするという中で、大きく以下のフェーズを実行します。
1) Reconnaissance(偵察)
  - ターゲットについての情報収集をするための探査を行う準備フェーズ
2) Mapping
  - サーバー、サービスの検出および識別をするためのフェーズ
3) Discovery
  - 具体的な脆弱性を特定するためのScanningフェーズ
4) Exploitation
  - 1) - 3) のフェーズで収集した情報を基に実際に攻撃をするフェーズ

このようにターゲットのパブリックな情報から具体的に稼働しているソフトウェア、アプリケーションの構成などから脆弱性を特定し、最終的に攻撃が実行される傾向にあります。

Akamai CLIのご紹介

弊社では昨年6月に作業の自動化が必要な方に向けて、統合された拡張可能なパッケージ管理ツールである Akamai CLI を発表しました。
また 配信設定を管理する為の Akamai CLI for Property Manager 、キャッシュパージの為の Akamai CLI for Purge というパッケージをリリース致しました。

今春のリリースでは Akamai CLI 1.0 が発表されましたので、アップデートをご紹介させていただきます。
今回は Visitor Prioritization Cloudlets 、Network Experience Analytics 、NetStorage(現在 プレビュー版)のパッケージも追加リリースしています。

前回、アカマイのデジタルパフォーマンス管理製品に加わったRUM ベースのソリューションである「mPulse」をご紹介しました。mPulseは、よく利用されるユースケースを想定したダッシュボード(以降、標準ダッシュボード)を多数用意しており、すぐに使えるパワフルなSaaS型のクラウドサービスです。今回は、mPulseをより高度にご活用いただける分析環境「データサイエンスワークベンチ(DSWB)」という付属ツールをご紹介します。

DSWB(データサイエンスワークベンチ)とは

mPulseではWEBパフォーマンスに関する様々なデータを蓄積しており、よく利用されるユースケースを想定した標準ダッシュボードをご用意しています。次のデモサイトで標準ダッシュボードを体験いただけます。デモサイトはこちら

一方、それら標準ダッシュボード以外の軸やチャートでのスライシング、ダイシング、ドリルダウンといった分析が必要になるケースが出てくると想定されます。それらダッシュボードを作成できる環境がDSWBです。お客様がより迅速に、より簡便に、状況の把握と意思決定を行うことを支援するダッシュボードのご提供を目的としています。DSWBを操作してダッシュボードを作成する作業は、弊社エンジニアによるプロフェッショナルサービスが前提となりますが、作成されたDSWBのダッシュボード(以降、DSダッシュボード)はmPulseの画面を通じて、お客様にてご利用することができます。

ゼロ・トラストの概念と「ゆでカエル」

ゼロ・トラスト・ネットワーキングとは?

ゼロ・トラスト・セキュリティモデルは、2010年にForrester ResearchのJohn Kindervag氏によって提唱されました。その概念は、従来の信頼モデルである「信ぜよ、されど確認せよ」はもはや有効ではないため、「決して信頼せず必ず確認」すべきである、というものです。

Frog 1.png

これは煮詰めていく(つまり要約する)と、ネットワークは、いかなるユーザーもデバイスも、その所在位置に基づいて信頼されていると仮定してはならない、という意味です。ネットワークの内部か外部かに関わらず、ユーザーとデバイスは、リソースにアクセスしようとするたびに必ず確認する必要があります。「煮詰める」といえば、いわゆる「茹でガエルの法則」におけるカエルはどうなったのでしょうか?

やや残酷な例えで恐縮ですが・・・もし冷たい水の入った鍋にカエルを入れて火をつけると、そのカエルは手遅れになるまで水温の上昇に気がつきません。

これを、ゆっくりと複雑かつ非効率になっていきつつあるネットワーク境界の管理状況に例えることができます。幸い、私達はカエルよりも賢明ですから、熱湯の中にいたらすぐ分かるし鍋から飛び上がって脱出することができますよね!

CMAF(Common Media Application Format)とは

2018年時点の HTTP Streaming の世界では、2017年に IETFでRFCとして承認されたApple が主導するHLS (HTTP Live Streaming) と、ISO国際標準規格である MPEG-DASH(Dynamic Adaptive Streaming over HTTP)という2つのメディアコンテナファイルのフォーマットが主に使われるようになっています。

より多くのユーザーにリーチしたいコンテンツの提供者は、それぞれの規格用にエンコードを行い、それぞれをストレージに保管する必要があります。複数のフォーマットに対応しなければいけないという事は、ファイルの変換コストと変換をしたメディアコンテナファイルを保管するコストを必要とするため、ストリーミング配信の複雑さと高コスト化の大きな要因となっています。

これらのメディアコンテナファイルのフォーマットの複雑さを解決するために、Apple Microsoft は、CMAF(Common Media Application Format) と呼ばれる共通の規格の策定をMPEGに提出し、20181月にISO/IEC 23000-19:2018として正式に発行されました[1]

CMAF では、マニフェストファイル自体は定義しておらず、普段目にしている mpd (MPEG-DASH)  m3u8  (HLS)と言ったマニフェストファイルが無くなるわけではありません。CMAF では、暗号化や、複数 Bitrate配信のためのリファレンスモデルが定義されており、ISO BMFF(ISO Base Media File Format) をメディアコンテナファイルのフォーマットとして使用する事が定義されています。ISO BMFFの現実の実装としては fragmented MP4 (fMP4)が広く使われています

署名バージョン4による認証ヘッダーを付ける

Akamai Edge Server上で、エンドユーザーから受け取ったHTTPリクエストに、AWSのアクセスキー(Access Key IDとSecret Access Key)を使用して生成した署名(署名バージョン4)を付けS3に送信する事が可能です。以前は Advanced実装扱いでしたが、現在は Property の Behavior を使用してユーザーが設定する事が可能です。

署名されていない一般ユーザーによるS3へのアクセスを防ぐ事ができますので、Akamai を通さない S3へのアクセスを許可したくない場合等に使用できます。また、AWSのアクセスキーを使うため、S3バケットに対する細かなアクセス制御を行う事も可能になります。

※ このBlog 記事は2018.3.2に執筆された Akamai SIRT Alerts のBlog 記事を翻訳した内容を元に作成しています。

先週、memcachedを利用したリフレクション攻撃が、DDoSシーンを席巻しました。Akamaiのお客様に対する史上最大の 1.3Tbps の攻撃をはじめとするいくつかの攻撃が様々な業種を襲っています。アカマイでは、メッセージをmemcachedの ペイロードにいれて脅迫を試みるという新しい傾向を観測しました。

※ このBlog 記事は2018.3.1に執筆された Akamai SIRT Alerts のBlog 記事を翻訳した内容を元に作成しています。

アカマイは2018年2月28日17:28 (グリニッジ標準時)に、ソフトウェア開発関連会社の顧客に対する、memcachedリフレクションを利用した1.3TbpsのDDoS攻撃を緩和しました。この攻撃は、アカマイが2016年9月にMiraiボットネットによるDDoSを発表した際の攻撃規模の2倍以上、おそらく本原稿執筆時点で一般に公開されている中でも、史上最大規模のDDoS攻撃となりました。しかし、memcached リフレクションのしくみ上、この記録を上回る規模の攻撃の出現は想像に難くありません。

ECサイトやチケットサイトを運用されている方は、期間限定セールや特定商品の発売、限定チケット販売等のピーク時に、どのように大量トラフィックを処理していけばいいかお悩みの方がいらっしゃるかと思います。
フロントのウェブサイトは問題無く閲覧できるのにバックエンドの購入処理システムのキャパシティが上限に達してしまったり、そもそもウェブサイト自体が閲覧できない状態になってしまったりすると、せっかくの商機を逃してしまう結果となります。
本稿では、そういった課題を解決するソリューション、Cloudlets Visitor Prioritization (VP)をご紹介します。
VP_1.png
1 2 3 4 5 6 7 8 9 10