Category: Security, Identity, & Compliance

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

本Blogでは日本時間の本日未明に終了した「AWS Public Sector Summit Online」 における、ブレイクアウトセッションのハイライトをご紹介いたします（記載は2020年7月1日時点）。 【キーノート編】も本日併せて公開されておりますので、ご参照ください（こちら。World Wide Public Sector部門のバイス・プレジデントであるテレサ・カールソンが登壇した基調講演のハイライトです）。　YouTubeでの動画公開が可能となり次第、各セッションへのリンクも貼られる予定です。 おすすめのブレイクアウト・セッション 以下、日本のお客様向けに、今回のサミットで開催された２５のブレイクアウト・セッションの中から幾つかをご紹介させていただきます（開催終了後も、こちらに登録いただくことで全セッションを聴講いただくことが可能です。 公共機関のＤＸ、マネジメント＆イノベーション系のセッション： “Critical components for transformation within an international government context” Céline Degrauwe（Digital Transformation Adviser for Government, AWS）は、次のように述べます。　いずれの国の政府機関にとっても、①「リーダーによる強力なコミットメント」、②“イノベーションを選好する文化の確立” – 例えば「デザイン・シンキング」を起点とし、市民のニーズからミッションとツールとしてのテクノロジーを逆算して設定、③データ・クラシフィケーションを自組織内で実施し、クラウドに相応しい分類方針をセットすることが必要──である旨、３つの考え方を紹介しています。例えば、“Gov.BR”の事例では、Brazilの政府機関では４００以上の新しいデジタルサービスを投入しています。AWSも、「Executive Education」を」 を標準3日間のコースとして提供し、政府部門のDXを支援しています。民間部門と公共部門の大部分の重要なデータは合致し、現代では多大な協働が期待されています。“Procurement is the gateway to innovation“とも述べ、各国でのクラウドの買い方に関する調達改革の必要性もこのセッションでは強調されました。 “Understanding optimizing costs with the AWS Cloud” ── David Lurie（Business Development Capture Manager Canada, Worldwide Public sector, […]

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

AWS Shield は、アプリケーションの脆弱性、不正なボット、分散サービス妨害（DDoS）攻撃から AWS で実行されているアプリケーションを保護する、マネージド型脅威保護サービスです。AWS Shield の脅威ランドスケープレポート（TLR）は、AWS Shield によって検出された脅威の概要が説明されています。このレポートは、AWS のお客様に代わって保護を構築するために、脅威状況を継続的に監視、評価している AWS 脅威リサーチチーム（TRT）によって作成されたものです。これには、 AWS WAF の AWS マネージドルール や AWS Shield Advanced など、サービスのルールと緩和策が含まれています。この情報を使用して、外部の脅威に関する知識を広げ、AWS で実行されるアプリケーションのセキュリティを向上させることができます。 2020 年第 1 四半期を対象とする最新のレポートから、調査結果の一部をご紹介します。

今や仮想化は、クリエイティブな専門家が在宅勤務で仕事をする上で必要な環境となりました。本ブログでは、AWSクラウド上でポストプロダクションアプリケーションを実行する場合に重要な考慮事項を説明します。

アマゾン ウェブ サービス （AWS）がはじめて PCI 3-D Secure (3DS) 認定を取得したことをお知らせいたします。AWS は 3DS 機能を直接提供しませんが、AWS の PCI 3DS準拠証明書により、お客様が AWS で実行されているサービスに対して PCI 3DS 準拠を実現できます。

2021年7月追記： AWSにおけるゼロトラストに関するアップデートされた情報は、以下をご参照ください。 https://aws.amazon.com/jp/security/zero-trust/ また、本Blogを詳細にアップデートしたBlog記事もありますので適宜ご参照ください。 「ゼロトラストアーキテクチャ: AWS の視点」 https://aws.amazon.com/jp/blogs/news/zero-trust-architectures-an-aws-perspective/ —————————————————————– 厳しい規制への対応やリスク回避を考慮事項として擁するお客様は、レガシーアプリケーションのリファクタリングや新しいアプリケーションのデプロイに際し、ゼロトラストアーキテクチャに関心を向けることがあります。このブログでは、お客様がお客様のアプリケーションを評価し、ゼロトラストの原則とAmazon Web Services (AWS)を利用して安全でスケーラブルなアーキテクチャを構築するための手助けを行います。 ゼロトラストとは？ ゼロトラストセキュリティとは、アプリケーションのコンポーネントやマイクロサービスが互いに分離しており、どのコンポーネントやマイクロサービスも他のコンポーネントやマイクロサービスを信頼していないというモデルです。これは、あらゆるソースからの入力を潜在的に悪意のあるものとみなすように設計されたセキュリティの考え方です。基礎となる内部ネットワーク・ファブリックを信頼しないことから始まり、さらにすべてのマイクロサービスにおける入力と出力の評価におよびます。加えて、個々のコンポーネント、マイクロサービス、またはアイデンティティの侵害から保護するために、多層防御アプローチを設計することも含まれます。 （訳者注：ゼロトラストは特定の製品やソリューションを指すものではなく多層的なセキュリティ手法を踏まえた概念として、現在アメリカ国立技術標準研究所（NIST）においても、SP800-207（本blog執筆時点においてはドラフト）として定義化が進められています。） 伝統的なネットワークセキュリティの設計は、セキュリティの境界に依拠します。境界内のすべてのものは信頼され、境界外のものは信頼できないものとみなされます。ゼロトラストネットワークは、ビジネスデータや機密リソースへの意図しないアクセスのリスクを低減するために、リアルタイムですべてのアクションとリソースを評価します。 ゼロトラストの原則を用いたAWS上での設計 ゼロトラストアーキテクチャをよりよく理解するために、脅威モデリングにより、従来のアーキテクチャやクラウドネイティブアーキテクチャとを比較してみましょう。脅威モデリングは、ユーザーはすべての潜在的な攻撃の可能性を評価してリスクを定義し、管理策を決定するための試みです。脅威モデルの一つであるSTRIDEでは、以下のようなカテゴリの脅威を特定しています。 ユーザーIDのなりすまし（Spoofing） データの改ざん（Tempering） ソースの否認（Repudiation） 情報漏洩（Information Disclosure） サービスの拒否（Denial of Service） 特権の昇格（Elevation of Privilege） AWSのベストプラクティスアーキテクチャ AWSでは、AWS上でWell-Architectedなアプリケーションを設計するための基礎となるツールを提供しています。AWS Well-Architected Frameworkは、AWSのベストプラクティスとワークロードを比較し、安定的かつ効率的なシステムを構築するためのガイダンスを得るための戦略を紹介しています。Well-Architected Frameworkには、セキュリティを含む5つの明確な柱が含まれています。このフレームワークを基に、ゼロトラストをAWSアーキテクチャに適用した例としてWebアプリケーションを考えてみましょう。 図1: Webサイトホスティングの例 表現されているアーキテクチャは、セキュリティを考慮したWell architectedの一例です。システムは、以下のサービスを活用して一般的な攻撃ベクターから保護されています。 Elastic Load Balancing (ELB)/Application Load Balancer (ALB)による負荷分散により、複数のアベイラビリティゾーンとAmazon Elastic Compute Cloud (Amazon EC2) Auto Scalingグループに負荷を分散し、サービスの冗長化と疎結合を実現します。 AWSのSecurity Groupを利用した仮想ファイアウォールでは、インスタンスにセキュリティを移動させ、Webサーバとアプリケーションサーバの両方にステートフルなホストレベルのファイアウォールを提供します。 […]

 AWS クラウドを採用している企業は、ID を効果的に管理したいと考えています。ID を一元的に管理することで、ポリシーの適用、アクセス許可の管理が容易になり、複数の ID サイロ間でユーザーとユーザー許可をレプリケートする必要がなくなるため、オーバーヘッドを削減できます。一意の ID を使用すると、ユーザーである私たち全員のアクセスも簡素化されます。私たちは皆、複数のシステムにアクセスできます。また、複数のパスワードを覚えておくのに苦労しています。ユーザー名とパスワードの単一の組み合わせを使用して複数のシステムに接続できれば、日々のセキュリティと生産性が向上します。あるシステムの ID を別の信頼できるシステムで管理されている ID にリンクできることを「ID フェデレーション」といいます。これは、シングルサインオンのサブセットです。ID フェデレーションは、セキュリティアサーションマークアップランゲージ (SAML)、OAuth、OpenID などの業界標準のおかげで可能になりました。 最近、AWS Single Sign-On が進化したことを発表しました。これにより、AWS ID を Azure Active Directory ID とリンクできるようになりました。進化はそこで止まりませんでした。今日、AWS Single Sign-On と Okta Universal Directory の統合を発表します。 この記事では、システム管理者向けのエクスペリエンスを紹介してから、ユーザー向けのシングルサインオンエクスペリエンスをご紹介します。 まず、私がすでに Okta Universal Directory を使って従業員 ID を管理している企業の管理者であるとします。次に、ユーザーのために、その既存の ID を使用して、AWS 環境へシンプルで難なくアクセスできるようにしたいと考えています。ほとんどの企業と同じように、私は複数の AWS アカウントを管理しています。シングルサインオンソリューションだけでなく、AWS アカウントへのアクセスを一元管理したいと考えています。Okta グループとユーザーメンバーシップを手動で複製したり、複数の ID システム (Okta Universal Directory […]

本Blogは、クラウドにおける新しい常識”new normal”を考えるBlogの第二弾です。（第一弾「クラウドにおける安全なデータの廃棄」はこちら） 今回は、クラウドの基本的な考え方である”責任共有モデル”をとりあげます。こちらのBlogをご覧の皆様の中には”何故、いまだに責任共有モデルなのか”という疑問を持つ方もいらっしゃるかもしれません。しかし、未だに本モデルの考え方や実際のビジネスへの適用方法は十分に理解されていないようにも見受けられます。今回は責任共有モデルとは何か？を振り返るとともに、いくつかの理解のポイントをお伝えします。 セキュリティ責任共有モデルとは？ ”セキュリティとコンプライアンスはAWSとお客様の間で共有される責任です。この共有モデルは、AWSがホストオペレーティングシステムと仮想化レイヤーから、サービスが運用されている施設の物理的なセキュリティに至るまでの要素をAWSが運用、管理、および制御することから、お客様の運用上の負担を軽減するために役立ちます。お客様には、ゲストオペレーティングシステム (更新とセキュリティパッチを含む)、その他の関連アプリケーションソフトウェア、およびAWSが提供するセキュリティグループファイアウォールの設定に対する責任と管理を担っていただきます。使用するサービス、それらのサービスの IT 環境への統合、および適用される法律と規制によって責任が異なるため、お客様は選択したサービスを慎重に検討する必要があります。また、この責任共有モデルの性質によって柔軟性が得られ、お客様がデプロイを統制できます。以下の図に示すように、この責任の相違は通常クラウド ’の’ セキュリティ(Security ‘of’ the Cloud)、およびクラウド ’における’ セキュリティ(Security ‘in’ the cloud)と呼ばれます。” 責任共有モデルを踏まえたセキュリティ効率性の改善 責任共有モデルを適用するうえでのメリットを考えてみましょう。例えばお客様がPCI DSS等の認証の取得を考えた場合、全ての要件を自社で管理を行うことは非常に負荷が高く、コストもかかる作業となります。AWSはPCI DSSを含めた様々なコンプライアンスプログラムや第三者認証に取り組んでおり、お客様は自らの認証の範囲からデーターセンターの物理的な統制を除外することができます。お客様はAWS Artifactからリポートを入手することで、物理統制の評価が可能となります。この場合、認証の範囲を縮小することは審査だけでなく運用上の負荷においても大きな便益をお客様にもたらします。 同様にAWSのサービスを考えた場合、Amazon EC2インスタンスにサービスを構築する場合と、Amazon RDSなどのマネージドサービスやAWS Lambdaなどのサーバレスアーキテクチャを活用してサービスを構築した場合では、パッチの適用やバックアップ管理等、セキュリティに関連する負荷は大きく異なります。サービス自体やセキュリティ管理策に対する運用の経済性を考えた場合、AWSにセキュリティ管理を任せることで、お客様はその分の投資をサービスの改善やより重要なワークロードに振り分けることができることになります。つまり、組織がガバナンス上で何を重要とするかといった考え方に基づき、選択肢を持つことが可能となります。 AWSは”クラウド内のセキュリティに対する責任”を助けないのか。 上記のモデル図で考えた場合、責任の分界点として、”ユーザのセキュリティに対してAWSは何もしてくれないのか”という疑問をもたれるケースがあります。もちろん、そうではありません。AWSは様々な手段でお客様のセキュリティの実現を支援します。第一に、AWSは豊富なセキュリティサービスや機能、アップデートを提供しています。AWSにおける脆弱性の発見等はセキュリティ速報に公開され、お客様はRSSフィードで購読することが可能です。これらにより、お客様は自らのニーズにあったセキュリティの実装や対応を行うことができます。次に、開発者ガイドや各種ホワイトペーパーなどをもとにお客様のセキュリティに対して必要な情報を提供しています。また、単に設定方法を伝えるだけではなく、Well Architectedフレームワークは、クラウドの特性を活かしたサービスの原則を提供することで、お客様のセキュリティを支援する道具になります。 また、支援は機能やサービスだけではありません。AWSではSolution Architectによる技術支援やProfessional Servicesによる有償コンサルティングサービスの提供、Certification and Training teamによるトレーニングサービスの提供、AWS Supportによるお客様課題の支援や対応窓口の提供など、様々な形での組織的な支援を行っています。例えばAWS Supportではナレッジセンターとしてお客様からのお問い合わせの頻度の多い質問に対する回答を公開しています。 また、お客様がコンプライアンスに準拠した環境でサービスを設計、運用するためには、実際の構築や運用の担い手となるパートナー様の尽力が不可欠です。政府機関における「政府機関等の情報セキュリティ対策のための統一基準群」に対するリファレンスや金融業界における「FISC安全対策基準」へのリファレンス等は、AWSJの協力に基づきAPNパートナー様により開発、公開されており、システムインテグレーターや開発、運用事業者はこれらを活用することが出来ます。 このようにAWSは組織的、技術的に様々なアプローチでお客様のセキュリティをサポートする手段を提供しています。 多くの”責任共有モデル”は二階層ではない。 上記のモデル図は”AWS”と”お客様”の二階層で責任共有を表現しています。しかし、様々な場合において、二階層で責任共有モデルを考えることは現実的ではないことがあります。例えば、日本では多くの調達や開発、運用において、システムインテグレーターや開発、運用事業者が存在する場合がありますし、例えばお客様がSaaS事業者と契約した場合、そのインフラストラクチャをAWSが提供している場合があります。こうした場合、セキュリティは重層的になります。実際にはお客様の中でも様々な責任共有の形があります。また、お客様の中にも責任共有モデルは存在します。事業部門とシステム部門、監査やリスク管理部門など、単一の組織においてもセキュリティの責任は複数の組織で共有しているものとなります。責任の範囲を明確にすることは本来は自然なことであり、まずは範囲を明らかにした上で、どのように協働をおこなうかというプロセスが重要になります。 重層的な責任共有モデルにどう向き合うか お客様がSaaS事業者やシステムインテグレーターと契約した場合、セキュリティに対する説明責任はそのような事業者自身がAWSが提供する様々な情報を活用してお客様と向き合うとともにセキュリティの実装などに責任を持つことになります。こうしたパートナー様のエコシステムの育成や拡充のために、APNパートナープログラムではセキュリティコンピテンシーやパブリックセクターコンピテンシー等、お客様が業界や技術に明るいパートナーを選択できる仕組みを提供しています。既にご説明したAPNパートナー様によるセキュリティリファレンスなどの取り組みも進展しています。また、お客様の中における責任共有モデルにおいても、AWSでは実際にお客様の様々なクラウド移行を支援してきた経験から、お客様内におけるクラウド推進組織であるCloud Center of Excellence (CCoE）の設立などをベストプラクティスとしてお客様にお伝えしています。 責任共有モデルは”セキュリティだけ”のものではない。 このような責任共有という考え方は、”セキュリティだけ”に適用されるものではありません。例えば、ある情報システムのクラウド移行を想定した場合にも、“移行計画”の策定、“予算”の見積もりと確保、“クラウド要件”の定義、“調達/購買”の実施、（特に公共部門の場合には）“契約”の締結、実際の“精算”・・といった一連のプロセスが伴います。ここで注目すべきは、ユーザ側・調達者側が上記の一連のプロセスにおいてガバナンスを強化することが望ましい「new normal」においては、従来のモデルとは責任主体や責任の共有の仕方が異なるケースが頻発する、ということです。例えば：  “予算”の見積もりと確保──クラウドのコストメリットは、従量課金により実際に使った分だけを支払うことができる点に求められます。旧来の情報システムの発注は、その運用までも含め、固定額で見積もられることがほとんどでした。しかしクラウドを前提とした予算の確保では、ユーザ側・調達者側が積極的にクラウド利用料金の実績値管理（その頻度は週次であったり、日次で行うことも可能です）に主体性を持ち、次年度（場合によっては次期四半期）の予算確保の精度を継続的に上げていくことが求められます。ツールとしてはAWS Cost Explorer等が役立つはずです。 “調達/購買”の実施──旧来の情報システムの“調達/購買”においては、システム・インテグレーター（SI）によってシステム構成要件の全てを満たすことが期待されていました。しかしクラウドを前提とした調達/購買においては、これらの要件をSI/AWS/調達者の三者（あるいは、リセラーを含めた四者）によって分担し、共有することが必要となります。SIに求めるべきことをクラウドサービス事業者に求めるべきではなく、その逆もまた然りであるため、両者には別途独立した要件を求めることが妥当です。 […]

AWS Control Tower のリリース後、多くのお客様からいただいていたご要望がありました。既存のAWS Organizations に AWS Control Tower をデプロイすることと、組織が持つ他のアカウントにもガバナンスを拡張することです。 このたび、AWS Control Tower を既存の AWS Organization にデプロイできるようになったことをアナウンスいたします。一方で、AWS Control Tower をデプロイする前に作成した AWS アカウント（ここでは「未登録アカウント」と呼びます）は、デフォルトでは AWS Control Tower ガバナンスの範囲外になります。そのため、これらの未登録アカウントは明示的に AWS Control Tower へ登録する必要があります。 既存アカウントを AWS Control Tower へ登録することで、アカウントベースライン（基本設定）と追加のガードレールが配備され、継続的なガバナンス（Continuous Governance）が有効になります。なお、アカウントを登録する前には、適切なデューデリジェンス（事前評価）を行う必要があります。以下に記載されている「考慮すべき事項」セクションの追加情報を参照してください。 このブログでは、AWS Organizations 内の 未登録 AWS アカウントと 未登録 OU(Organization Units = 組織単位)内のアカウントを、プログラムによって AWS Control Tower へ登録する方法を解説します。