Amazon Web Services ブログ

Category: Networking & Content Delivery

siem-sample-dashboard

AWS サービスのログの可視化やセキュリティ分析を実現する SIEM on Amazon Elasticsearch Service 公開のお知らせ

みなさん、こんにちは。セキュリティ ソリューション アーキテクトの中島です。先日(2020年10月23日)にオープンソースで公開した SIEM on Amazon Elasticsearch Service (Amazon ES) をご紹介します。SIEM on Amazon ES は、セキュリティインシデントを調査するためのソリューションです。AWS のマルチアカウント環境下で、複数種類のログを収集し、ログの相関分析や可視化をすることができます。 SIEM on Amazon ES とは SIEM は Security Information and Event Management の略で、セキュリティ機器、ネットワーク機器、その他のあらゆる機器のデータを収集及び一元管理をして、相関分析によって脅威検出とインシデントレスポンスをサポートするためのソリューションです。Amazon ES は、オープンソースの Elasticsearch と Kibana を大規模かつ簡単でコスト効率の良い方法を使用してデプロイ、保護、実行する完全マネージド型サービスです。Amazon ES の環境に SIEM として必要な機能を実装したのが SIEM on Amazon ES です。

Read More

[AWS Black Belt Online Seminar] AWS App Mesh Deep Dive 資料及び QA 公開

先日 (2020/10/22) 開催しました AWS Black Belt Online Seminar「AWS App Mesh Deep Dive」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20201014 AWS Black Belt Online Seminar AWS App Mesh Deep Dive AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. APM として New Relic を採用しています。 Envoy のコントロールプレーンとして Istio を利用した場合New Relic 提供の newrelic-istio-adapter が利用できますが、Envoy のコントロールプレーンとして AWS App Mesh を利用した場合どのような方法があるのか教えていただけますか?Roadmap の話は QA 対象外ということですので、現時点での代替案、ワークアラウンドなどについて教えていただけますか? A. 現時点では、New Relic を利用する方法はありませんが、Envoy のメトリクスについては、Prometheus でのモニタリング、または […]

Read More

サーバーレス LAMP スタック – Part 4: サーバーレス Laravel アプリの構築

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 本シリーズの他のパートは以下のリンクからアクセスできます。また、関連するサンプルコードはこちらの GitHub リポジトリにあります。 パート1:サーバーレス LAMP スタックの紹介 パート2:リレーショナルデータベース パート3:Webサーバーの置き換え パート5:CDK コンストラクトライブラリ パート6:MVC からサーバーレスマイクロサービスへ この投稿では、サーバーレスアプローチで Laravel アプリケーションをデプロイする方法を学びます。 これは「サーバーレス LAMP スタック」シリーズの4番目の投稿になります。過去の投稿はこちらです。 パート1:サーバーレス LAMP スタックの紹介 パート2:リレーショナルデータベース パート3:Webサーバーの置き換え Laravel は PHP 用のオープンソースの Web アプリケーションフレームワークです。フレームワークを使用すると、開発者は一般的なコンポーネントとモジュールを再利用することで、より速く構築できます。また、開発標準に準拠することにより、長期的なメンテナンスにも役立ちます。ただし、従来の LAMP スタックを使用して PHP フレームワークをスケーリングする場合は、まだ課題があります。サーバーレスアプローチを使用してフレームワークをデプロイすると、これらの課題の解決に役立ちます。 Laravel アプリケーションのサーバーレスインフラストラクチャへの展開を簡素化する方法は数多くあります。ここで紹介する方法では、AWSサーバーレスアプリケーションモデル(AWS SAM)テンプレートを使用しています。これによって、Laravel アプリケーションが単一の Lambda 関数にデプロイされます。この関数は、Bref FPM カスタムランタイムレイヤーを使用して PHP を実行します。AWS SAMテンプレートは、「サーバーレス LAMP スタック – パート3: […]

Read More

サーバーレス LAMP スタック – Part 3: Webサーバーの置き換え

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 本シリーズの他のパートは以下のリンクからアクセスできます。また、関連するサンプルコードはこちらの GitHub リポジトリにあります。 パート1:サーバーレス LAMP スタックの紹介 パート2:リレーショナルデータベース パート4:サーバーレス Laravel アプリの構築 パート5:CDK コンストラクトライブラリ パート6:MVC からサーバーレスマイクロサービスへ この投稿では、Web サーバーを使用せずにサーバーレス PHP アプリケーションを構築する方法を学びます。 この投稿の後半で、bref および Serverless Visually Explained の作成者である Matthieu Napoli が FastCGI Process Manager の実装を Lambda 関数内で使うことでそれを可能にする方法を説明しています。Bref は、PHP 用のオープンソースのランタイム Lambda レイヤーです。 また、プライベート Amazon S3 バケットから静的アセットを安全に提供およびキャッシュするように Amazon CloudFront を構成する方法を示します。動的リクエストは、その後 Amazon API Gateway にルーティングされ、単一の […]

Read More

自治体情報セキュリティクラウドにAmazon CloudFrontを利用する

次期自治体情報セキュリティクラウドの見直し 総務省が2020年5月に公開した「自治体情報セキュリティ対策の見直しのポイント」では、次期自治体情報セキュリティクラウドの見直しのポイントが整理されており、追加の対策としてContent Delivery Network(CDN)の活用が求められています。自治体情報セキュリティクラウドとは、各県が県及び市町村のインターネットゲートウェイを集約し共通化したセキュリティ機能及びSOC(セキュリティ専門人材による監視機能)を民間事業者に委託のうえ提供しています。県によっては公式ホームページ等のWebサーバをホスティングとして提供していることもあるでしょう。昨今、災害時等インターネットからの通常時とは異なる大量のウェブアクセスや DDoS 攻撃を受けることで、ウェブサーバ処理能力の限界到達又は接続回線帯域の圧迫となり、コンテンツ提供の遅延や提供不可となりうる状況が懸念されています。住民・自治体双方にとって公式ホームページは市民接点となる重要サービスの位置づけであり、災害等の有事の際にも常時利用できるように対応しておく必要があります。Webサーバへのキャッシュ対応及び DDoS 対策として、コンテンツ配信サービス機能を導入し、DDoS 対策も講じることは、自治体情報セキュリティクラウドに限ったことでなく自治体が独自に運用しているWebサーバにおいても必須と言えるでしょう。 なぜAWSのCDNを利用するのか? Amazon CloudFrontが配置されているエッジロケーションは日本国内だけで 18 拠点以上あり,これは3年前(2017年)と比較して3倍以上の数に増えています。AWSのCDNではありますが、元データの存在元(オリジン)はAWS以外の環境(オンプレミスなど)でも利用することが可能です。 Amazon CloudFrontは、AWS Shield Standardというマネージド型の分散サービス妨害 (DDoS) に対する保護サービスと連携され、追加料金なく、インフラストラクチャ (レイヤー 3 および 4) を標的とする既知の攻撃を総合的に保護できます。また、クライアント端末の所在地(国情報)を判別し挙動に反映できる補完機能をもっており、特定国、地域等からの攻撃を遮断する機能を有します。Amazon CloudFront では、SSL/TLS 経由でコンテンツや API、アプリケーションを配信できるため、高度な SSL 機能が自動的に有効になります。 アクセス・トラフィック量の確認が管理コンソールより GUI で可能であり、トラフィック量が超過した場合などにアラーム(メール)などでの通知が可能です。さらに、AWS WAFを併用することで、一般的なWebの脆弱性からWebアプリケーションまたは API を保護するWebアプリケーションファイアウォールを適用し、SQLインジェクションのような、Webアプリケーションへの不正な通信を検知・防御することが可能です。また、これらのサービスは、クラウドの特徴を生かした完全従量課金であるため初期費用がゼロで始められる点などコストパフォーマンスが良いため、公共機関を含む多くの日本のお客様にご利用いただいています。Amazon CloudFront、AWS WAF共に、ISO/IEC27017:2015 の認定を受けています。 自治体情報セキュリティクラウドを踏まえた利用パターン 自治体の公式ホームページにおいて導入実績が多いCMS(LAMP構成)を想定したAWS上で構成する際の構成例(図1)を記載します。 ①オリジンはオンプレミス ・Webサーバ、CMSは従来のセキュリティクラウドに配置し、CDNの機能にAmazon CloudFront、そしてAWS WAFを利用します。BCP対策としてWEBサーバのコンテンツをAmazon S3へコピーします。 ②オリジンもAWSへ移行 ・Webサーバ、CMSをAWSへ移行し、CDNの機能にAmazon CloudFront、そしてAWS WAFを利用します。BCP対策としてWEBサーバのコンテンツをAmazon S3へコピーします。オリジンとなるWebサーバ、CMS、データベースをAWSに移行することで、容易にマルチAZ構成に対応できるため、一層継続性の高いサービスを提供することが可能です。 ※図1 自治体CMSの構成例 まとめ 自治体情報セキュリティクラウドの見直しに合わせて、自治体公式ホームページ等のWebサイトにAmazon […]

Read More

Amazon CloudFront ログを使用したリアルタイムダッシュボードの作成

Amazon CloudFront は AWS グローバルネットワークを使用して、静的および動的なウェブコンテンツを低レイテンシかつ高速で安全に配信するコンテンツ配信ネットワーク (CDN) です。 この度 CloudFront でリアルタイムに利用可能な、デリバリーログを配信する機能が発表されました。このリアルタイムログには、CloudFront が受け取った全てのリクエストに関する詳細情報が含まれます。詳細な情報をリアルタイムで確認することで、運用イベントに迅速に対応できるようになります。 リアルタイムログでは、収集する情報とその配信先をカスタマイズできます。リアルタイムログは Amazon Kinesis Data Streams と統合されており、Amazon Kinesis Data Firehose を使用して一般的な HTTP エンドポイントにログを配信できます。 Amazon Kinesis Data Firehose では Amazon S3、Amazon Redshift、Amazon Elasticsearch Service (Amazon ES)、および Datadog、New Relic、Splunk などのサービスプロバイダにログを配信できます。このログを使用して、リアルタイムダッシュボードの作成、アラートの設定、異常の調査や運用イベントへの迅速な対応を行うことができます。追跡できる一般的なデータポイントとしては、異なる地理的リージョンからのビューアーリクエスト数や、レイテンシが高いユニークビューアー数などがあります。

Read More

学 術 情 報 ネ ッ ト ワ ー ク SINET ク ラ ウ ド 接 続 サ ー ビ ス で の AWS利 用 で SINET大阪DC経由も選択可能となりました

学術情報ネットワークSINETは、国立情報学研究所(NII)が構築、運用している日本全国の大学や研究機関などの教育研究機関が接続された情報通信ネットワークです。このたび 学術情報ネットワーク (SINET) 大阪 DC 経由でのSINETクラウド接続サービスが利用可能となりました。これまでも SINET 東京 DC1 経由で複数の10Gbps 回線で接続されておりましたが、このたび協賛企業様のご協力もいただき SINET 大阪 DC 経由においても複数の 10Gbps 回線で接続されました。 今回の SINET 大阪 DC 経由の追加により、いわゆるSINET経由での SINET 利用形態として、 SINET クラウド接続サービス利用での SINET 東京1 DC 経由や SINET 大阪 DC 経由、通常の SINET-IX ピアリングでの利用の経路がそれぞれ利用可能となります。 SINET クラウド接続サービスと通常利用( IX 経由)での接続についての説明は以前ブログにてご紹介いたしました内容をご覧ください。 SINET 大阪 DC 経由の SINET クラウド接続サービスの利用についても、お客様が利用される際の負担は、これまでと同じくAWS側から見でdata outとなるデータ転送料金だけとなります。物理回線費、ポート占有にかかる費用に関してはお客様の負担なくご利用いただけます。 SINETならびにSINETクラウド接続サービス自体が基本的にベストエフォートであり、SLA等が規定されてるわけでは無い点を理解した上で、例えば東京リージョンで基幹系システムをご利用の場合、東京リージョンとの接続をSINETクラウド接続サービスのSINET東京1DC、SINET大阪DC経由の両方を利用することでSINET-AWS間を冗長化するなどが考えられます。 これまでと同様、SINETクラウド接続サービスに関しましては、国立情報学研究所のSINET担当、AWS側の両方へ申請が必要となります。AWS側の申請に関しましては sinet@amazon.com までお問い合わせください。尚、研究でSINETクラウド接続サービスを利用されている場合には、データ転送料金を低減するプログラムに参加可能な場合がございますので営業 (aws-jpps-er@amazon.com) までお問い合わせください。 — パブリックセクター ソリューションアーキテクト […]

Read More

[AWS Black Belt Online Seminar] AWS App Mesh 資料及び QA 公開

先日 (2020/07/31) 開催しました AWS Black Belt Online Seminar「AWS App Mesh」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200721 AWS Black Belt Online Seminar AWS App Mesh AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. サービスメッシュはマイクロサービスアーキテクチャを構築する当初から導入すべきでしょうか?それとも、ある程度の規模になってから導入するべきでしょうか? A. マイクロサービスアーキテクチャを採用したワークロードを新規構築する様な場合は、当初から導入することを検討いただければと思います。一方で、規模が小さい間からマイクロサービスアーキテクチャで構築するべきか?といった観点も必要になります。最初はモノリスで開発し、ある程度の規模になって運用の中でシステムのコンテキスト境界が見えてきた段階でマイクロサービスをサービスメッシュと合わせて検討する、といった例もございます。 Q. アプリケーション間の直接通信からサービスメッシュへ移行するためのコスト・タスク量について知りたいです。 A. サービスメッシュへ移行するためのマイグレーション手段はいくつか考えられますが、Envoy を導入したアプリケーションを別途作成し、既存のアプリケーションを縮退させる方法などが考えられます。上記の作業に関して、アプリケーションの規模や通信方式によって移行コストやタスク量が異なってきますので、まず、検証環境でマイグレーションを実施し、事前にコストやタスク量を見積もるよう推奨いたします。 Q. AppMesh と Istio の互換性について教えて下さい A. App Mesh と Istio は、サービスメッシュとしてのモデルや API に互換性はありません。 Q. AWS Lambda のネットワーク通信でも App Mesh は適用可能でしょうか?それとも、もともとの Lambda の設定を見直すだけでApp Meshの機能の一部でも実現可能でしょうか? […]

Read More

AWSを通じて日本取引所グループ(JPX)のarrownetにアクセスをする

“undifferentiated heavy lifting”という言葉をしばしば聞くことがあると思います。これは、競合他社との差別化にはなりえない作業にリソースを大量に消費することを言います。たとえば、サーバを構築し、OS にセキュリティパッチを適用するようなことです。このような作業は、より付加価値が高い製品やサービスを生み出すための活動から、ヒト・モノ・カネを奪い去ります。AWS では、お客様起点の重要な役割として、作業を簡素化し、自動化できるクラウドによるソリューションによって、開発者を”undifferentiated heavy lifting”から解放できるように支援しています。 金融業界では、過去20年間で大きな進歩を遂げています。たとえば、キャピタルマーケットの領域では、クラウドによるマーケットデータの活用により、トレーディングチームはリアルタイムでより良い洞察を導き出し、増え続けるデータからリスクをより効率的に計算できるようになりました。 しかしながら、いくつかの企業にとって、”undifferentiated heavy lifting”はまだ存在しています。それらの1つは、金融機関が規制機関や取引所によって設定された規制や業界ルールを遵守しなければならないことに関連しています。市場参加者は、これらの市場ルールを遵守する必要があり、遵守しない場合はペナルティを受ける場合もあります。 金融業界は、進化し続ける要件の複雑さと細分性が高まっている世界で最も規制の厳しい業界の1つです。しかし、金融機関がコンプライアンスに投資するすべてのリソースについて、多くは義務から機会への移行を行えていません。言い換えれば、ほとんどの金融機関では、同業他社との差別化を図るのではなく、ビジネスを行うためのコストとして、依然として規制やコンプライアンスを捉えています。 野球で例えるならば、プレイヤーはゲームのルールに従わなければなりませんが、優れたプレイヤーは、常に個人とチームの両方のレベルでパフォーマンスを改善するために戦略と戦術を使用しています。同様に、企業は規制要件に対応する必要がありますが、合理化、自動化、コスト効率の高い方法でそれに対応する必要があります。 このブログでは、日本取引所グループ (JPX) が AWS でどのように市場参加者にとってより良い顧客体験を生み出しているかをお話します。JPXは、これまでネットワークへのアクセスに関連していた”undifferentiated heavy lifting”を排除することで、市場参加者が新しいサービスのテスト、構築、立ち上げに向けてリソースを再利用できるようにしています。 JPXは、メンバー企業のクラウドでの市場アクセスを強化 2020年5月、JPX は市場参加者が AWS Direct Connect を介して、売買システムや清算決済システムなどにつながる高信頼ネットワークである arrownet にアクセスできるようにしました。 以前は、会員企業がarrownetに接続したい場合、JPXと自社のオフィスやデータセンター間に専用線を注文し、そのうえでネットワーク構築やセキュリティ対策を実施する必要がありました。このネットワーク構成は、変動する市場に迅速に対応するための信頼性と安定性が必要で、さらに十分な通信容量を提供する必要がありました。回線が接続されると、市場参加者は24時間365日体制で監視し、ハードウェア障害に対応するために人的リソースも投下する必要がありました。また専用線ベンダー側の監視にも、これらの重要なタスクのための人件費とサポート費も付属しています。つまり、arrownetへの接続は、利用者が長年にわたって対応してきた”undifferentiated heavy lifting”とも言えます。 JPXは、市場参加者からフィードバックを取り入れ、arrownetをクラウドに拡大し、市場参加者のアクセスを簡素化しました。市場投入までの時間が短縮され、マーケットからのデータを AWS 環境で扱うことで、マーケットの変動に対してオンデマンドで拡張できるようになります。 JPX は AWS Direct Connect の仮想インターフェイスを提供します。これにより、会員企業は短い期間でarrownetに接続して、テストすることができます。その結果、AWS の利用者は、以前は専用回線接続で直面していた”undifferentiated heavy lifting”な作業をすることなく、クラウド環境でマーケットからのデータを受け取ることができます。 現在の会員企業がこの合理化されたマーケットアクセスの恩恵を受けるだけでなく、FinTech スタートアップも恩恵を受けることができます。多くの Fintech スタートアップは AWS のサービスを使用しているため、彼らの既存の環境をより効果的に活用するには、クラウドネイティブ接続が必要でした。マーケットへの迅速なアクセスができるようになったFintech スタートアップは、新製品やサービスの市場投入までの時間をさらに短縮することができるでしょう。 現在、AWS Direct Connect により、JPX […]

Read More

Amazon CloudFront キャッシュポリシーとオリジンリクエストポリシーを発表

Amazon CloudFront の新しいキャッシュポリシーとオリジンリクエストポリシーにより、CloudFront がリクエストデータを使用して、キャッシュキーとキャッシュミス時にオリジンに転送されるリクエストの両方に影響を与える方法をより詳細に制御できます。これにより CloudFront が実行するキャッシュの制御と効率を向上させながら、さらに柔軟性が高まります。これらの設定はすでに部分的には存在していましたが、キャッシュキーの設定はオリジン転送の設定から独立することになります。以前は転送されたデータのほとんどはキャッシュキーを自動的に変更していました。このポリシーにより、ほとんどのリクエスト要素をキャッシュキーに影響を与えることなくオリジンに転送できるようになります。ヘッダー、Cookie、およびクエリ文字列パラメータの任意の組み合わせを設定して、キャッシュキーとして考慮するよう含めたり、除外したり、必要に応じて転送したりできます。 基本的な設定の柔軟性の向上に加えて、これらのオプションは “ポリシー” を使用して設定されるようになりました。ポリシーでは、同様の設定の組み合わせを任意の数のディストリビューションに適用できます。これによりセットアップ時間が短縮され、複雑さが軽減されてチームは全体の設定にわたって一貫性を管理できます。

Read More