Amazon Web Services ブログ

Category: AWS Config

Systems Manager Automation Runbook でスクリプトを活用する

お客様は今まで、 AWS Systems Manager Automationドキュメントを使用して、AWS Lambda 関数の呼び出しや Amazon Machine Image (AMI) のコピーなど、AWS インフラストラクチャで実行する一連のアクションを定義してきました。これらのドキュメントは現在 Runbook と呼ばれており、簡単に使用でき、かつ強力です。 aws:executeScript アクションを使用すると、Python と PowerShell を Runbook に直接埋め込むことができます。

Read More

AWS を活用したオープンバンキング ~ データ受信企業における実装方法

本投稿は AWS のソリューションアーキテクトである Akash Jain による寄稿を翻訳したものです。 2017年11月26日、オーストラリア政府は、消費者データ権 (CDR)の導入を発表しました。オーストラリア競争・消費者委員会 (ACCC)によって管理される CDR は、消費者が自分のデータをより詳細に制御し、商品とサービスの比較や乗り換えする能力を高めることを目指しています。例えば、フィンテックはオープンバンキングデータを使用することで、消費者に最も適したクレジットカードやローンを見つけやすくします。AWS パートナーである Adatree のオープンバンキングユースケースレポートには、このようなユースケースが多数記載されています。CDR によって推進される透明性は、住宅ローン、個人ローン、クレジットカード、貯蓄口座などの銀行商品の価格競争の強化につながるだけでなく、消費者データを活用する革新的な製品やサービスにつながります。

Read More

AWS Config ベストプラクティス

AWS Config は、AWS リソースの設定履歴を維持し、ベストプラクティスと内部ポリシーに対して設定を評価するサービスです。この情報は、運用上のトラブルシューティング、監査、コンプライアンスのユースケースに使用できます。このブログ記事では、企業全体のガバナンスを可能にするツールとして AWS Config を使用する方法のベストプラクティスを紹介します。 1.すべてのアカウントとリージョンで AWS Config を有効にします。 これは、Center for Internet Security (CIS) が推奨する業界のベストプラクティスです。AWS Config を使用すると、AWS リソースの設定を監査し、設定のベストプラクティスに確実に準拠することができます。AWS CloudFormation StackSets を使用すると、共通の CloudFormation テンプレートを使用して、複数のアカウントとリージョンで AWS Config を有効にできます。 2.すべてのリソースタイプの設定変更を記録します。 AWS Config をセットアップするときは、AWS Config に記録する必要があるリソースタイプとして [すべてのリソース] を選択します。AWS Config は AWS で 60 を超えるさまざまなリソースタイプをサポートしているため、これにより包括的な設定監査が実施されます。新しいリソースタイプは、この設定を介して自動的に記録されます。3.1 つのリージョンでのみグローバルリソース (IAM リソースなど) を記録します。 これにより、IAM 設定アイテムの冗長コピーをすべてのリージョンで取得することがなくなります。それは費用の節約にもなります。 4.設定履歴とスナップショットファイルを収集する安全な Amazon S3 バケットがあることを確認してください。 Amazon S3 バケットは、AWS […]

Read More

大手金融機関におけるセキュリティ・コンプライアンスのためのイベント管理

本投稿では、商業銀行として米国で Top 25 内にランクインしている金融機関であるBBVA USAが、AWS サービスを使用して大規模なイベント管理の仕組みを実装し、クラウド環境に関連する変更イベントを一元管理し、アクションを自動化した方法について紹介しています。一般的に、モノリシック環境でのセキュリティ・コンプライアンスは、管理・監視対象となるインフラストラクチャが少ないため、監視と実施が比較的容易です。それが多くなったとしても、インフラストラクチャをコード化すれば、民主化され分散化されたアプローチによって、コンプライアンスの見落としなく構成の差分管理(ドリフト)と追跡処理を環境に取り入れることができます。 インフラストラクチャの正常な状態を識別し、そこから外れた違反状態を把握することにより、インフラの状態の可視性が確保され、必要に応じて自動修復によって遵守を強制させることが可能になります。このために、セキュリティイベントの通知やベースラインとなる構成定義といった機能を使うことができます。

Read More

AWS ConfigでSAPシステムを評価する – パート2

はじめに パート1では、AWS Configマネージドルールを使用してSAPランドスケープのを自動的に監査および評価する方法をお伝えしました。また、お客様のEC2インスタンスがSAPのベストプラクティスに従って設定されていることを確認するソリューションをお伝えしました。現在、AWSはバージニア北部リージョンでは160を超えるマネージドルールを提供しています。 インフラストラクチャに加えて、お客様はアプリケーションのコンプライアンスを維持する必要もあります。ここでは、AWS Configカスタムルールについてご説明します。AWS Configカスタムルールを使用すると、マネージドルールでカバーされているものに加えて、独自の構成チェックを定義できます。基本的にAWS Configカスタムルールは、AWSリソースのリストに対してAWS Lambda関数を実行します。

Read More

AWS ConfigでSAPシステムを評価する – パート1

はじめに SAP on AWSをご利用のお客様は、SAPシステムの日常運用を強化し単純化できる幅広い追加サービスを利用可能です。よく見かける面倒なタスクの1つとして、SAPシステムがベストプラクティスに従って構成されているかどうかということや、ベンダーサポートの要件を満たしているか、内部監査要件を満たしているかどうか、という点があります。 このブログシリーズでは、AWS Configがお客様のランドスケープ内の全てのSAPシステムのコンプライアンスを継続的に監査および評価するプロセスを簡素化する方法についてご説明します。また、Amazon Event BridgeおよびAmazon Simple Notification Serviceを使用して、リソースが非準拠として識別された場合にEメール通知を有効にする追加手順をお届けします。

Read More

[AWS Black Belt Online Seminar] AWS Config update 資料及び QA 公開

先日 (2020/12/08) 開催しました AWS Black Belt Online Seminar「AWS Config update」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20201208 AWS Black Belt Online Seminar AWS Config update AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. 適合パックの変更不可とは、ルール策定時にカスタマイズ不可という意味ではなく、一度適用されたら適用された側が例外条件を加えて適用除外するようなことはできない、という意味で正しいでしょうか A. はい。デプロイされた適合パックは、その他のアカウントやアクセス権限によって、評価内容の変更やの除外を行うことができません。また適合パックの内容は、ルール策定時にカスタマイズが可能です(カスタムテンプレート機能) Q. 50個あるのは嬉しいですが、どれが自分のサービスに適合されるか効率よく、確実な1つのテンプレートの見つけ方はありますか? A. 評価を行いたいAWSサービスやアーキテクチャが具体的に決まっていれば、その「運用ベストプラクティスの適合パック」をまず確認いただくのがよいかと存じます。(サーバレス、EC2、ストレージサービスなど) Q. “適合パックによるアカウント特性や組織特性に応じた評価” スライド上の人物アイコンは、AWS アカウントを指していますか? A. はい、ご認識の通りです。AWS Organizations で管理されるAWSアカウント(メンバーアカウント)を意味しております。 Q. 本セミナーに直接関連するものではありませんが、こちらの資料( re:Invent 2019: MGT408 – Best practice for detecting and preventing data exposure ) p.12にある […]

Read More

re:Invent 2020におけるマネジメントとガバナンス関連セッションのご紹介

AWS re:Inventは、お客様と関わり合い、サービスや機能に関して学び、共有できる、エキサイティングな時期です。現在のパンデミックにより、今年のre:Inventは11月30日から12月18日までの 3 週間にわたって完全オンライン、無料で開催されます。そうです、あなたには参加する権利があるのです。 AWS re:Invent 2020はバーチャルで開催され無料です!!! このブログでは、AWSでのマネジメントとガバナンスに関するセッションのハイライトを紹介します。これらは、ビジネスの俊敏性とガバナンスコントロールの両者を維持しながら、AWS環境を有効化し、プロビジョニングし、そして運用するために、役立つセッションです。各セッションは、世界各地のお客様に向け複数回ブロードキャストされ、すべてあなたの家で快適な環境でご視聴いただけます。これらのセッションのメリットを享受するため、re:Inventに登録してください。

Read More

委任された管理者からAWS Configルールと適合パックをデプロイする

AWS Configルールの使用により、リソースの構成をベストプラクティスに照らし合せて評価し、決められた構成ポリシーに従っていない場合は修正することができます。 AWS Config適合パックを使用すると、AWS Organizations全体に適用されるAWS Configルールと修復アクションのセットを単一のパックで作成できます。これにより、Configルールの集中管理と展開が可能になります。 今までは、組織全体にまたがる適合パックとConfigルールの展開は、組織のマスターアカウントのみが実施できました。しかし、マスターアカウントを一括請求にのみ使用するお客様も多数おられます。お客様がセキュリティ、監査、コンプライアンスのための専用アカウントを持っている場合、代わりにその専用アカウントを使って組織全体にわたるConfigの展開を管理したいと考えるでしょう。このようなご要望にお応えして、AWS Organizationsの非マスターアカウントからConfigルールと適合パックのデプロイができるようになりました。このAWS Config新機能を使用すると、これらのConfigリソースをAWS Organizations全体に展開し管理できる権限を委任する管理者アカウントを登録できます。 このブログ投稿では、委任された管理者アカウントにて、組織全体に適合パックを展開し、AWS Configルールと適合パックを管理する方法について示します。

Read More

クラウドサービスの評価を最適化する方法

本投稿はワールドワイドで金融業界を担当しているプリンシパル・テクニカルプログラムマネージャーの Jennifer Code による寄稿を翻訳したものです。 私の同僚の Ilya Epshteyn が、 金融機関が機密性の高いデータのためにAWSサービスを承認する方法 というタイトルのブログでご紹介したように、金融業界では一般的にクラウドサービスの正式な評価プロセスが存在します。これらの評価プロセスは深さや幅に関しては様々ですが、いずれのプロセスも、業界の期待とテクノロジーリスク管理の健全性を確保しつつ、ビジネス要件を満たすのにはどのクラウドサービスが最適かを決定しようとするものです。このブログでは、クラウドサービスに対する新たな評価プロセスを構築する、または既存の評価プロセスを最適化する際に役立つシンプルなガイダンスを提供します。 私は、お客様と頻繁に会ってお客様のガバナンスとクラウドの評価プロセスについてディスカッションをしますが、その中でよく耳にするテーマがいくつかあります。1つ目は、評価プロセスが正式に存在する場合であっても、オーナー不在の場合が多く、結果としてそのプロセスが達成すべきビジネス上の成果を必ずしも理解しないまま、チームがプロセスに従っているという問題です。強いオーナーシップがなければ、参加者と評価範囲に一貫性が保てません。また、時には、構造化されたフレームワークではなく、個々の専門知識とベストエフォートに依存しているため機能性に差異が生じている場合もあります。最後に、お客様は、ほとんど例外なく、知識の共有を進めつつ、繰り返し学ぶことによって、評価プロセスの質を一気に向上させる方法があるのではと感じています。 正式なクラウドサービス評価プロセスがとても重要なのはなぜでしょうか? 金融サービス会社は、テクノロジーリスクの監視を証明するという、共通の規制上の義務を負っています。従来、企業のリスクフレームワークは、サイロ化された「3 つのラインによる防御」または (3LoD) で構成されていました。第一のラインはリスクの所有者としてコントロールを実行するビジネス / 運用担当者、第二のラインはリスクのモニタリングとコントロールの評価を行うリスク管理担当者、第三のラインは独立または内部監査人、またはリスクアシュランス担当者で構成されています。これらの 3LoD はそれぞれ、テクノロジーリスク、一般的な社内のポリシーの収集、ならびに他の防御ラインによって行われた一連の評価・監査に合わせて自チーム内で文書化された手順についての責任を負ってきました。 この既存の企業リスクフレームワークにクラウドの評価プロセスを組み込むことで、組織は重要な技術上の意思決定がどのように行われたかを適切に証明できるようになります。また、リスクがどのように評価され、軽減されるか、コントロール環境の強さがリスクアペタイトにどのように適合しているかといった点を、クラウドベースのサービスの微妙な差異に焦点を当てつつ説明できるようになります。 クラウド評価を最適化するためのヒント 金融サービスのお客様の期待を念頭に置き、お客様がクラウド評価プロセスを構築または改善するために実行できる3つのアクションを提案します。 ガバナンス体制の正式化。ガバナンス体制が正式に確立されていない場合、金融サービス機関がとるべき最初のステップは、クラウドのガバナンスとコントロールに関してエンドツーエンドの責任を担うC-レベルの経営幹部を任命することです。 プラットフォーム コントロールの優先順位付け。クラウド評価を策定する際に、優先順位と要件について、クラウド・プラットフォームとビジネス・アプリケーション機能の区分を取り入れます。セキュリティとレジリエンスのためのプラットフォームレベルのコントロールを最初の優先事項として重要視します。ビジネス・アプリケーションの機能に視点が移った時に、クラウドプラットフォームから継承されたコントロールに基づいて評価を調整できるようになります。 継続的な改善の組み込み。 知識共有と継続的な改善は、Day 1から明確に優先されるべきです。積極的な透明性があることにより、コントロールが構築され評価が行われる際に、3つの防御ラインすべてにわたっての信頼が築かれることが期待されます。意識的かつ積極的な共有によって、コントロールが設計されており、最初の本番ユースケースに対しても効率的に実行することができるという自信につながります。 AWSの使用量と専門知識が増えるにつれて、コントロールの強化と適用範囲の継続的な改善も容易になります。 ガバナンス体制の正式化 重要な最初のステップはクラウドのガバナンスに対する完全な説明責任を持つ適切な Cレベルの経営幹部を特定することです。この個人は、はじめにクラウドのガバナンスとコントロールのトーン設定を行い − クラウドの評価、使用状況、および継続的なモニタリングのための構造とプロセスを構築する責任をもちます。重要なのは、組織全体の専門知識を活用して、十分に制御されながらアジリティのある環境を確立するよう促す意欲のある、強力でポジションの高いリーダーを任命することです。 そのガバナンスのリーダーは任命され次第、評価プロセスを形成する機能横断的な構造、成文化されたポリシーと必要となるガバナンスプロセスを正式化し、現在進行中の評価のサポートをしなくてはなりません。私の経験では、正式なガバナンスの枠組みに支えられた多様な専門知識を活用できるバーチャルなチームが最も効果的です。 効果的なクラウドガバナンスの考慮事項 効果的なクラウドガバナンスの目標を定め、専門知識を正当に評価する企業全体のクラウド戦略 は、導入と使用状況を測定しながら時間をかけて構築します。 クラウドガバナンスに責任のある経営幹部を任命、従事、およびコミットすることで全体的なガバナンス構造に統合し、継続的なモニタリングを行います。 知識が豊富で 参加を約束できる(3 つの防御ラインにまたがった)リスクとコントロールのステークホルダーをクラウドのガバナンス活動における正式な参加者 にします。 企業のガバナンス フレームワークとプロセスに準拠することで、クラウドイネーブルメントチームの存在を明確にします。 定義されたプロセスを組織に伝達するとともに、承認されたクラウドサービスのみを利用していることを確実にする自動強制機能を使用します。 プラットフォーム コントロールの優先順位付け 私と顧客とのやり取りでよく見られたパターンは、クラウドサービスを評価するにあたり、たった1つのアプローチを作成し、それを全てのパターンに当てはめようとするやり方です。これは典型的に、各サービスを個別に評価する形式をとり、多くの場合、体系的に完成された詳細なチェックリストを伴います。 なぜこれが理想的ではないのでしょうか? 第一に、これは各サービスへの脅威は同等であることを前提としています(したがって、同じ評価が必要なコントロールを決定する適切な方法とされます)。第二に、このタイプのアプローチでは、評価者が能力または機能により区別することは認めていません(たとえば、データを中心としたサービスとコンピューティング サービスの違いを考慮しません)。最も重要な点は、既存の統制基盤を考慮していないことです(したがって、追加のコントロールの必要性を過大評価してしまう可能性があります)。 私が見てきた中で最も効果的だったのは、交渉不可能な基盤を確立した上で、環境、データの機密性、ビジネスの重要性など、他の要因に基づいて必要なコントロールを追加する、段階的なコントロール フレームワークです。この区分けによって、不適切なレベルのリスクを発生させることなく、実験を行うことができます。具体的には、すべてのデータタイプ、すべての環境において最初から予防的統制でなければならないコントロールもありますが、その他のコントロールではモニタリングをサポートすることによって、発見的統制から始めることが許容できるかもしれません。適切にコントロールされたイノベーションが目標です。 […]

Read More