Decryptorなど)と呼ばれるランサムウェア(身代金マルウェア)による被害が世界中から報告されはじめました。日本でも複数の大手企業がこのマルウェアに感染したというニュースが報道されています。SMBサーバー上に存在する脆弱性を悪用します。デフォルトでは、SMBサーバーはUDPポート137/138およびTCPポート139/445で動作します。Server(4013389)の重要なセキュリティ更新プログラムをリリースしました。EC2上のWindowsに関しては、AWSから提供されている2017.04.12以降のリリースのAMIであれば、この脆弱性の被害を受けていません。自動更新が有効になっている場合も、この脆弱性は解消されています。2017.04.12より前のAMIを使用している、かつ、自動更新を有効にしていないお客様は、前述のセキュリティ更新プログラムをインストールすることをお勧めします。AWSでは、セキュリティのベストプラクティスに従い、セキュリティグループの設定を確認し、その必要のあるインスタンスおよびリモートホストに対してのみ前述のポートへのアクセスを許可することを、常にお勧めしています。デフォルトでは、EC2セキュリティグループはこれらのポートをブロックします。AMIのリリースノートはこちらです。WorkSpacesのお客様は、この脆弱性の影響を受けません。WorkSpaceを終了して再作成することをお勧めします。Serviceに関しては、2017/05/20時点でパッチ適用作業が完了しました。お客様による対応は必要ありません。この問題の影響を受けていません。最新情報につきましては、下の原文へのリンク先をご参照ください。Shareロギングとデバッグ情報は、さまざまな角度からアプローチできます。アプリケーションフレームワークを使用する場合でも、一からコーディングする場合でも、異なるプロジェクト間で使い慣れたコンポーネントやツールを使用することは常に快適です。Logsに出力させます。これを実現するために、すでに普及しよく利用されている標準に準拠した既存のソリューションを使いたいと思っていました。Monolog(https://github.com/Seldaek/monolog)を使用します。新しいPHPアプリケーション、フレームワーク、またはサービスを扱う人にとって、ソリューション間で頻繁に現れる技術の選択肢の1つとしてアプリケーションログ用のMonologを利用することが挙げられます。Monologは標準に準拠したPHPライブラリで、開発者はデータベース、ファイル、ソケット、さまざまなサービスなどのさまざまな種類のフォーマットにログを送信できます。MonologはPSR-3で定義されたPHPロギングの標準化よりも前に、PSR-3のインターフェースと標準を実装していました。これにより、Monologはロギングライブラリ用の共通インタフェースに準拠しています。LogsでMonologを使用すると、PSR-3互換ロギングソリューションが作成されます。Monologは、Laravel、Symfony、CakePHPなど多くの異なるアプリケーションやフレームワークで使用できます。Monologを使用してCloudWatchLogsに情報を送信し、CloudWatchのアラームと通知でアプリケーションデータを使用できる構造とプロセスを構築することです。AutoScalingのようなサービスのアクションに使用することができます。顧客第一主義の組織として、AWSはお客様やAWSパートナーが要望する重要な機能やサービスを絶えず構築し、リリースしています。Logsを使用すると、アプリケーション、オペレーティングシステムおよびインスタンス、AWSサービス、およびその他のさまざまなソースからのログファイルの情報を保存できます。Logsをさまざまなプログラミング例とともに紹介しました。Logsを使用してアプリケーションからのエントリを保存するPHPの例があります。Logsにログを送ることができます。Monologを活用してこの機能を強化します。Monologを使用開始するには、Composer(https://getcomposer.org/)を使用して必要なライブラリをインストールします。Logsへのログを有効にするMonologのアドオンをインストールします。installコマンドでインストールすることもできます。ブログのコレクションが拡大しました。右側のリストをご覧になれば分かるように、現在では実に幅広い様々なトピックや開発ツールに関するブログをご提供しています。ブログをご覧いただくことができます。コスト管理、大規模なオンプレミスリソースの管理について説明しています。テンプレート、ユースケースのディスカッションなども含まれています。ブログ開始当初の投稿をいくつか以下にご紹介します。ShareAWSリソースを安全に保護するためのアプローチとして、予防のための仕組み、検知のため仕組みといったそれぞれのレイヤーでのアプローチを検討頂くことを推奨しています。EC2インスタンスにホストベースのコントロールを組み込むことで、アクセスを制限し、システムの動作やアクセスパターンに伴う適切なレベルの可視性を準備できます。これらのコントロールには、ホスト上のネットワークトラフィック、ログファイル、およびファイルアクセスを監視・分析するホストベースの侵入検知システム(HIDS)を含むことが一般的です。ソリューションと統合され、攻撃、許可されていない活動、疑わしい活動、環境内の一般的なエラーを検出し対処します。Logsを使用してオープンソースセキュリティ(OSSEC)HIDSからのアラートを収集、集約する方法を示します。ES)に分析データと可視化のアラートを配信し、一般的なオープンソースであるKibanaを使用し可視化まで行います。皆さんが、すぐに試せるようにCloudFormationテンプレートを用意しましたので、ほとんどのデプロイメント作業を自動化させています。全体の可視性と洞察を向上させ、セキュリティ修復活動を促進することができます。WAFルールを実装して、送信元IPアドレスまたはCIDRをブロックすることができます。次の図は、この記事のソリューションの概要を示しています。ソリューションの仕組みは次のとおりです。エージェントがキャプチャするログに基づきアラートを生成します。HIDSは、ログ分析、整合性チェック、Windowsレジストリ監視、ルートキット検出、リアルタイムアラート、およびアクティブな応答を実行します。詳細については、「OSSEC入門」を参照してください。グループはにアラートがイベントとして送信されます。サブスクリプションがターゲットロググループに適用されます。ESにはログに記録されたアラートデータがロードされます。Kibanaはアラートをほぼリアルタイムで視覚化します。ESドメインにKibanaを標準でインストールした形で提供されます。HIDSのデプロイは、Linuxベースのインストールで構成されています。インストールでは、アラートが各システム内でローカルに生成されます。ESとLambdaに依存します。AWSサービスの可用性に関する最新情報は、Regionテーブルで確認できます。Cloud)サブネットを識別する必要があります。CloudFormationテンプレートを作成しました。VPCサブネットに自動的にプロビジョニングできます。CloudFormationを使用してこのソリューションのコアコンポーネントをプロビジョニングし、警告分析用にKibanaを設定します。このソリューションのソースコードはGitHubで入手できます。サービスで実行しているアプリケーション、システム、ソリューションをモニタリングできるサービスです。使用率などの主要メトリックスが自動的に測定されます。お客様から提供されたログやシステムデータに基づくカスタムメトリックスのモニタリングも可能です。新しいダッシュボードウィジェットが追加され、すべてのメトリックスのデータを視覚化できるようになりました。実行しているソリューションやリソースの状態を把握しやすくなりました。このアラームの追加により、アラームとメトリックスを同じダッシュボードウィジェットで確認して、データに基づくトラブルシューティングと分析を行うことができます。リソースを統合されたビューでモニタリングする際の可視性を高めるためのものです。ダッシュボードは高度にカスタマイズ可能であるため、ユーザーは独自のダッシュボードを作成して使用率、パフォーマンス、請求予定額、そして今回のアラーム状態など、さまざまなメトリックスのデータをグラフィカルに表示できます。アラームは、各メトリックスの値と指定したしきい値の関係を経時的に追跡します。ポリシーなどのアクションが実行されます。リソースやアプリケーションをモニタリングして事前にアラートを受け取る手段が増えました。ダッシュボードに追加されたアラームでは、メトリックスのデータをグラフで確認できます。