Akamai Japan ブログ 購読
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そのものの技術仕様についてはこちらを参照ください。
ゼロデイ攻撃対策にも繫がる Client Reputation
以前寄稿した「AKAMAI と SIEM と CLOUD SECURITY」でも述べさせていただきましたが、近年のサイバーセキュリティは高度化、迅速化がより重要なキーワードとなっております。迅速化の一例として、2018年の Apache Struts2の脆弱性に対しての攻撃では、弊社観測情報として脆弱性の情報公開から２日未満でその脆弱性を突いた攻撃が行われ、その１日後には大規模な攻撃キャンペーンに至った、という例もございます。こちらはあくまで公開できる情報からの参考となりますので、ボットネットが攻撃プラットフォームとして容易に利用できるようになってしまっている昨今では、例えバーチャルパッチの位置付けであるWAFソリューションを導入していたとしても攻撃への迅速な対処という観点では万全であると言えない状況となっております。 本稿でご説明する AKAMAI の Client Reputation は既に別の投稿でも説明がある通り、この 「Apache Struts2 の脆弱性に対しての攻撃＝ゼロデイ攻撃を未然に防御する」という大きな効果を発揮した AKAMAI の Cloud Security ソリューションとなります。当時の状況については「APACHE STRUTS2脆弱性攻撃のゼロデイ防御に成功！」の投稿をご参照いただくとして、その中で活躍した Client Reputation について掘り下げてご説明させていただきます。
ゼロトラスト・セキュリティ・アーキテクチャ：アカマイのアプローチ
この記事は、5 部構成のブログシリーズの、第5部です。 第1部: 「イントロダクション」 へ 第2部: 「ネットワークのマイクロセグメンテーション」 へ 第3部: 「ソフトウェア定義境界」 へ 第4部: 「アイデンティティ認証プロキシ（IAP）」 へ 第5部: 「アカマイのゼロトラスト・アプローチ」 へ
ゼロトラスト・セキュリティ・アーキテクチャ：ID認識型プロキシ
この記事は、5 部構成のブログシリーズの、第4部です。 第1部: 「イントロダクション」 へ 第2部: 「ネットワークのマイクロセグメンテーション」 へ 第3部: 「ソフトウェア定義境界（SDP）」 へ 第4部: 「ID認識型プロキシ（IAP）」 へ 第5部: 「アカマイのゼロトラスト・アプローチ」 へ
ゼロトラスト・セキュリティ・アーキテクチャ：ソフトウェア定義境界
この記事は、5 部構成のブログシリーズの、第3部です。 第1部: 「イントロダクション」 へ 第2部: 「ネットワークのマイクロセグメンテーション」 へ 第3部: 「ソフトウェア定義境界（SDP）」 へ 第4部: 「ID認識型プロキシ（IAP）」 へ 第5部: 「アカマイのゼロトラスト・アプローチ」 へ
ゼロトラスト・セキュリティ・アーキテクチャ：マイクロセグメンテーション
この記事は、5 部構成のブログシリーズの、第2部です。 第1部: 「イントロダクション」 へ 第2部: 「ネットワークのマイクロセグメンテーション」 へ 第3部: 「ソフトウェア定義境界（SDP）」 へ 第4部: 「ID認識型プロキシ（IAP）」 へ 第5部: 「アカマイのゼロトラスト・アプローチ」 へ
展示会の様子を紹介します（Inter BEE 2018編）
皆様はIT関連の展示会に参加された事はありますでしょうか？アカマイは映像・配信関連の展示会に年に数回程度出展しています。展示会は、アカマイがその時最も力を入れている製品・サービスは何なのか？あるいは、実際に製品が動いている所を見てみたい、アカマイに聞いてみたい事がある！と思われている方には絶好の機会だと思います。今回は展示会でのアカマイの様子を紹介させていただきますので、お立ち寄りいただく際の参考にしていただければと思います。
ゼロトラスト・セキュリティ・アーキテクチャ
※ このBlog 記事は、こちらの記事を翻訳した内容を元に作成しています。 この「イントロダクション」は、5 部構成のブログシリーズの、第1部です。 第1部: 「イントロダクション」 へ 第2部: 「ネットワークのマイクロセグメンテーション」 へ 第3部: 「ソフトウェア定義境界（SDP）」 へ 第4部: 「ID認識型プロキシ（IAP）」 へ 第5部: 「アカマイのゼロトラスト・アプローチ」 へ
アカマイ エンタープライズ ソリューション のアップデート
2017年1月にアカマイはエンタープライズ ソリューション発表し、約2年ほど経過しました。これらの製品は、企業のゼロトラスト・セキュリティを実現するための新たなソリューションですが、アカマイがこれまで実現してきた高速化・セキュリティのソリューション群とも非常に親和性の高いものです。 ゼロトラスト・セキュリティについての概要は下記リンクをご参照ください。 https://blogs.akamai.com/jp/2018/12/post-12.html 単純にセキュリティを高めるだけのゼロトラスト・セキュリティではなく、クラウドとして提供することで運用効率を高め、それに加えアカマイが得意とするパフォーマンスの向上・高度なセキュリティサービスを追加で提供することで企業に必要なあらゆる要素を包括的に提供できることができます。 このブログでは、エンタープライズ ソリューション についての現状の主なアップデート内容を解説させて頂きます。 Enterprise Threat Protector (ETP) についての概要は下記リンクをご参照ください。 https://blogs.akamai.com/jp/2017/12/akamai-enterprise-threat-protector-etp.html Enterprise Application Access(EAA)についての概要は下記リンクをご参照ください。 https://blogs.akamai.com/jp/2017/02/---enterprise-application-access.html