Akamai Diversity

Akamai Japan ブログ

Kazuhiro Nakanishi

Kazuhiro Nakanishi

June 25, 2019 6:21 PM

AKAMAI の Security Configuration のアップデートに関するご案内

※ このBlog 記事は2019.4.10に執筆されたAkamai Developer blogの記事を翻訳した内容を元に作成しています。 Akamai Security Configuration の 4 回目にして最後となる UX アップデートが完了したことをお知らせします(4 つの段階についてはこちらを参照)。最新バージョンでは開発者および管理者向けのプロセスが効率化され、タスク完了までの時間が短縮されたほか、保護機能がさらに強化されました。これにより、将来 Akamai が新機能を追加するための強力な基盤となっています。Akamai の Kona Site Defender、Bot Manager、Client Reputation、Web Application Firewall については、次の 4 つのセキュリティ設定の領域で機能強化が行われました。 設定の概要とチューニングステータスのページ 設定バージョン比較ツール アクティブ化履歴 「Protection Coverage」を「Hostname Coverage」に変更 注:これらの新しい機能強化は現在、Akamai の Security Configuration のベータ版ユーザーのみご利用いただけます。2019 年 5 月にはすべてのユーザーにご利用いただける予定です。弊社は改良を加えたバージョンがユーザーの皆様に歓迎されること、およびシームレスな体験を提供できることを確信しています。ただし、ベータ版のご利用中に予期しない問題が発生した場合は、[Back to Classic View]ボタンをクリックして以前のバージョンに戻ることが可能です。 ここからは上述の 4 つの機能強化のそれぞれについて、もう少し詳しく説明します。

Norihiko Matsuno

Norihiko Matsuno

May 29, 2019 1:00 PM

ENHANCED PROXY DETECTIONによる不正視聴対策のご紹介

アカマイCDNを通して、映画やアニメなど様々なコンテンツが世界中に配信されております。そしてそれらのコンテンツは特定の地域でのみ配信が許可されるべきライセンスコンテンツであることも多々あり、ユーザーの地域判別とアクセス制御の仕組みが必要です。その仕組みはアカマイのContent Targetingという機能で提供されております。それはIPアドレスと地域情報を紐づけたデータベースを参照することでエンドユーザーの地域を特定、アクセス制御するというものですが、VPNを使われると地域判定ができなくなるという側面もありました。本稿では、その抜け道を塞ぐENHANCED PROXY DETECTION (EPD)という新しい機能をご紹介いたします。 ※ この記事は2019.3.4に執筆されたThe Akamai Blogの記事を元に加筆、作成しています。

Yasutada Sato

Yasutada Sato

May 29, 2019 12:00 PM

Web Application Protector による API Protection

インターネットを流れるトラフィックの中でも、近年APIトラフィックは特に増加傾向にあります。利用者が増え、トラフィックが増えるにつれて攻撃者たちも活動範囲を広げてきていますのでAPIに対してもセキュリティ対策が求められています。※ この記事は2019.3.4に執筆されたThe Akamai Blogの記事を翻訳した内容を元に作成しています。

Mio Tsuchihashi

Mio Tsuchihashi

April 26, 2019 11:00 AM

DATASTREAM - リアルタイムロギングの実社会における利点

近年CDNの領域でも、システム全体の安定運用のためにリアルタイムなログの収集および分析が重要になっています。そこで今回はAkamaiのリアルタイムロギングソリューションであるData Streamとその活用方法についてご紹介いたします。※ この記事は2019.3.4に執筆されたThe Akamai Blogの記事を翻訳した内容を元に作成しています。

Takayuki Sano

Takayuki Sano

April 26, 2019 10:45 AM

ハイブリッド&マルチクラウド時代のグローバルトラフィックマネジメント

※ この記事は2019.3.6に執筆されたThe Akamai Blogの記事を翻訳した内容を元に作成しています。 20年前は複数のデータセンターを負荷分散するために専用デバイスを利用することは一般的であり、複数のデータセンターにホストされたアプリケーションはDNSを使用して宛先となるデータセンターに割り振られていました。DNSシステムはデータセンター単位で設定するため、データセンター間を「ラウンドロビンに割り振られる」結果となっていました。仮に4つのデータセンターを利用している場合であれば、ユーザーは各データセンターを「ラウンドロビンに割り振られる」結果となってしまいます。DNS参照によるラウンドロビンは本質的には負荷分散とは言えるのものではありません。設計者は複数の物理的な場所またぎトラフィックを分散し、過負荷となっているデータセンターに対してはトラフィックを減少させるツールを必要としていました。また、ユーザに最も近いデータセンターが選択され、地理的に負荷分散できるツールについても必要としていました。さらにデータセンターに障害が発生した場合にはトラフィックが再ルーティングされるリカバリーオプションも必要としていました。これらに対応するソリューションとしてグローバルサーバーロードバランサー (GSLB) が生み出されました。GSLBはアプリケーションが属するゾーンに対するプライマリ DNS サーバーになります。通常GSLBはデータセンター毎に1つ設置され、他のデータセンターの負荷を監視し、各ユーザーのクエリを最も適切で、最も近い、かつ負荷の低いデータセンターに割り振ります。またGSLBはデータセンターの障害や過負荷を回避することが可能です。GSLBは異なるデータセンターに配置されたプライマリおよびセカンダリGSLBが連動しリカバリーを実現します。

Yuhki Hanada

Yuhki Hanada

March 27, 2019 9:00 AM

DevOpsを加速するAkamai CLI - CLI を使用したキャッシュの purge

こんにちは、Akamai Solutions Engineer のYuhki です。 以前から AKamai では、Akamai の製品を HTTP リクエスト経由で使用できる Web APIを提供してきましたが、一昨年からさらにそれらを使いやすくした Akamai CLI (Command Line Interface) の提供を開始しました。Akamai CLI とは、これまで Akamai {OPEN} API で提供していたプリミティブなレベルの複数の操作を組み合わせ、まとめた形で簡単なコマンドとして実行できるようしたものです。Akamai {OPEN} API では簡単な操作をするにもある程度のプログラミングが必用でしたが、Akamai CLI ではより簡単な手順で Akamai のサービスの機能をコマンドラインから取り扱う事ができるようになります。開発・運用局面の自動化プロセスへの Akamai サービスの取り込みがより簡単にできるようになり DevOps への取り込みも楽になっています。コマンドですのでバイナリ形式で提供されていますが、ソースコードは、 GitHub で公開されています。 この記事では Akamai CLI のパッケージ構造、実際にインストールして purge 作業を実行するまでの具体的な作業について解説致します。

Masahiko Suzuki

Masahiko Suzuki

February 27, 2019 3:00 PM

GraphQL Caching について

はじめに GraphQL (Query Language)は、Facebookにより開発され、2015年にリリースされたAPI用のデータクエリ言語であり、REST APIの次のパラダイムとして益々注目されています。GraphQLの主な特徴として、クライアントが送出するAPIコールであるHTTP POST Bodyにサービスに必要なリソースを明示的に記述することで、過剰なAPIコール数の削減や、レスポンス内の余分な情報を無くすことでペイロードサイズの削減ができる点などがあげられます。また、基本的に単一のエンドポイントのみを利用すること、APIのバージョンという概念が存在しないことなどもGraphQLの特徴となります。 REST APIと比較して利点が多いように思われるGraphQLですが、一つの課題としてCDNにおけるキャッシュが難しいという点があげられます。REST APIにおける多くのケースでは、APIリソース毎にURLが一意であれば、URLをベースにキャッシュキーを生成する事ができます。(「キャッシュキー」についてはこちらをご参照ください。)一方、GraphQLでは単一のエンドポイントのみを利用し、HTTP POST Bodyの内容によってレスポンス結果が異なるため、URLベースでキャッシュキーの生成ができず、これまでのCDNの仕組みではキャッシュを実現する事ができません。結果として、CDNによるオリジンサーバのオフロードを実現ができなかったり、クライアントのパフォーマンスやユーザ体験に影響を及ぼす可能性があります。 このような課題を解決するために、昨年リリースしたAkamai API Gatewayという製品における拡張機能として、「GraphQL Caching」が実装されました。本機能ではGraphQLで記述されたリクエストに対して、HTTP POST BodyのParseおよびHash値を取り一意のキャッシュキーを生成することで、GraphQLで呼び出されたレスポンス結果をCDN上のエッジサーバーでキャッシュすることが可能になります。 本ブログではGraphQL Cachingについて具体例を交えて説明したいと思います。尚、GraphQLそのものの技術仕様についてはこちらを参照ください。

佐々木 貴志

佐々木 貴志

February 27, 2019 2:00 PM

ゼロデイ攻撃対策にも繫がる Client Reputation

以前寄稿した「AKAMAI と SIEM と CLOUD SECURITY」でも述べさせていただきましたが、近年のサイバーセキュリティは高度化、迅速化がより重要なキーワードとなっております。迅速化の一例として、2018年の Apache Struts2の脆弱性に対しての攻撃では、弊社観測情報として脆弱性の情報公開から2日未満でその脆弱性を突いた攻撃が行われ、その1日後には大規模な攻撃キャンペーンに至った、という例もございます。こちらはあくまで公開できる情報からの参考となりますので、ボットネットが攻撃プラットフォームとして容易に利用できるようになってしまっている昨今では、例えバーチャルパッチの位置付けであるWAFソリューションを導入していたとしても攻撃への迅速な対処という観点では万全であると言えない状況となっております。 本稿でご説明する AKAMAI の Client Reputation は既に別の投稿でも説明がある通り、この 「Apache Struts2 の脆弱性に対しての攻撃=ゼロデイ攻撃を未然に防御する」という大きな効果を発揮した AKAMAI の Cloud Security ソリューションとなります。当時の状況については「APACHE STRUTS2脆弱性攻撃のゼロデイ防御に成功!」の投稿をご参照いただくとして、その中で活躍した Client Reputation について掘り下げてご説明させていただきます。

Haru Kaneko

Haru Kaneko

December 24, 2018 7:00 PM

ゼロトラスト・セキュリティ・アーキテクチャ:アカマイのアプローチ

この記事は、5 部構成のブログシリーズの、第5部です。 第1部: 「イントロダクション」 へ 第2部: 「ネットワークのマイクロセグメンテーション」 へ 第3部: 「ソフトウェア定義境界」 へ 第4部: 「アイデンティティ認証プロキシ(IAP)」 へ 第5部: 「アカマイのゼロトラスト・アプローチ」 へ