本ブログは 2026 年 5 月 19 日に公開された AWS Blog、” CIRT insights: How to help prevent unauthorized account removals from AWS Organizations ” を翻訳したものです。 AWS Customer Incident Response Team (CIRT) は、お客様がアクティブなセキュリティインシデントから復旧するためのご支援を行っています。この活動の中で、特定の お客様の構成や設計 を悪用する、新しいまたは流行している攻撃手口を発見することがしばしばあります。 これらの手口を理解することは、アーキテクチャ上の意思決定への反映、対応計画の改善、そして実際にこのような状況が発生した場合の検出に役立ちます。 本投稿では、攻撃者がお客様アカウントの制御を奪取した後に取る新しいアプローチを取り上げます。具体的には、お客様の AWS Organizations 実装から該当アカウントを離脱させ、その構造が提供するポリシーや保護を回避する手口です。 本記事で説明する手口は、AWS サービスの脆弱性を利用するものではありません。代わりに、特定の構成や設計によって生じた予期しない機会を悪用し、AWS アカウント内のリソースを不正に使用するものです。 何が起きているのか このアプローチは、攻撃者が organizations:LeaveOrganization 権限の付与を持つクレデンシャルを使用するところから始まります。この権限は LeaveOrganization API コール へのアクセスを提供し、メンバーアカウントから呼び出されると、そのアカウントを Organization から離脱させようとします。 重要な点として、このアプローチでは侵害されたルートクレデンシャルが使われる場合もありますが、攻撃者は他の手段でアクセス権を昇格させ、必要な権限を取得したり、その権限を持つロールを引き受ける能力を獲得したり、現在のクレデンシャルにこの権限を付与する能力を獲得したりすることもできます。これが、認可に対して 最小権限のアプローチ を取ることが、お客様の環境を保護する上で極めて重要である理由です。詳細については、 AWS Identity and Access Management (IAM) ドキュメント と、 組織単位 (OU) 設計および サービスコントロールポリシー (SCP) 実装に関する AWS Organizations のガイダンスをご覧ください。 お客様の環境への影響 アカウントが Organization から離脱させられると、その Organization の一部として継承されていた制限 (破壊的なアクションを防止していた SCP、利用可能な AWS リージョンを制限していたもの、特定の API コールをブロックしていたもの等) が適用されなくなります。また、当該アカウントは一括請求 (Consolidated Billing) の対象外となるため、Organization の請求アラートやコスト異常検知も該当アカウントの活動をカバーしなくなります。 AWS CloudTrail の組織トレイルは離脱したアカウントからのイベント取得を停止し、委任管理者を介して管理されていた Amazon GuardDuty の検出結果も中央のセキュリティアカウントへ流れなくなります。 その結果しばしば発生するのは、Organization が当該アカウントへの可視性を失う一方で、そのアカウント内には引き続き Organization のリソースが残るという状況です。関連する Threat Technique Catalog のエントリを以下に示します。 T1078.A002: Account Root User : 侵害されたルートクレデンシャルを利用した初期アクセス T1078.004: Cloud Accounts : 侵害された IAM クレデンシャルを利用した初期アクセス T1098: Account Manipulation : 制御を維持するための権限昇格とアカウント設定の変更 T1666.A002: Leave AWS Organization : SCP やガバナンスコントロールを回避するため、メンバーアカウントを Organization から離脱させる T1562.008: Disable Cloud Logs : Organization からの離脱後、中央集約型ロギングの可視性が失われる この手口の検知 アカウントが Organization からの離脱を試みると、CloudTrail には少なくとも 2 つの API コールが記録されます。 organizations:AcceptHandshake と organizations:LeaveOrganization です。中央集約型のロギングを構成している場合、これらのイベントが侵害アカウントから観測される最後のイベントとなる可能性があります。Organization からの離脱後、デフォルトではアカウント内のイベントは自身の CloudTrail ログに記録されることになります。アカウントが Organization に参加または離脱する際に関連する CloudTrail イベントを以下に示します。これらのイベントは、AWS Organizations を管理するためにチームが利用する承認済みの運用ワークフローの一部でない限り、調査が必要です。 CloudTrail イベント 意味 LeaveOrganization メンバーアカウントが Organization から離脱しようとしている AcceptHandshake アカウントが別の Organization への参加招待を承諾している InviteAccountToOrganization Organization がアカウントを招待している RemoveAccountFromOrganization 管理アカウントがメンバーアカウントを削除している (メンバー自らが離脱する場合とは異なる) この手口を防ぐための推奨ステップ organizations:LeaveOrganization アクションを拒否する SCP を実装してください。AWS Organizations は この制御の実装に関する詳細なガイダンス を提供しており、具体的な SCP ポリシー JSON や、本番環境および開発環境のアカウントには保護を維持しつつ正当なアカウント移行を許容できる OU 構造の設計に関するアドバイスが含まれています。 SCP は、メンバーアカウント内で IAM ポリシーが許可できる範囲を制限するガードレールとして機能します。AWS Organizations をご利用のすべてのお客様には、この SCP が現在配置されているかを確認し、配置されていない場合には実装に向けた手順を踏むことを強く推奨いたします。この SCP は迅速にデプロイでき、運用上の影響も最小限です。メンバーアカウントを Organization から分離することを慎重に管理・検討するためのプロセスを提供します。 このアクションは、ルートだけでなく organizations:LeaveOrganization 権限を持つあらゆる侵害された IAM プリンシパルから発生し得るため、IAM 権限の最小権限原則は重要な補完的な制御となります。ユーザーやロールがポリシーの追加・削除・変更を行ったり、別のロールを引き受けたり、自身の権限を変更したりできる範囲を制限することで、不正な権限変更が行われる経路を減らすことができます。IAM ポリシーを定期的にレビューし、過度に広範な権限 (特に iam:AttachRolePolicy 、 iam:AttachUserPolicy 、 iam:PutRolePolicy 、および広範な信頼ポリシーを伴う sts:AssumeRole ) を確認することは、侵害されたプリンシパルが実行できる範囲を制限するのに役立ちます。 ルートアカウントのセキュリティは引き続き重要です。ルートの侵害がこのパターンの一般的な侵入経路となるためです。すべてのルートユーザーに対して多要素認証 (MFA) を有効化し、ルートアクセスキーを削除し、メンバーアカウントからルートクレデンシャルを完全に取り除く ルートアクセスの一元管理 を採用することで、リスクの軽減につながります。 今後について 本手口は、私たちが様々なエンゲージメントを通じて目にしている、より広範なテーマを浮き彫りにしています。攻撃者は AWS のガバナンスコントロールがどのように機能するかをますます認識しており、Organization が提供する制御からアカウントを切り離すための意図的な手段を取っています。AWS CloudTrail を無効化する、Amazon GuardDuty ディテクターを削除する、Organization からアカウントを離脱させるといった行為は、いずれも同じ戦略の派生形にあたります。すなわち、本来であれば攻撃者の活動を制約し、お客様による対応を支援するはずのガードレールと可視性から、お客様のアカウントを切り離すというものです。 これを防ぐための制御は本日時点で利用可能であり、実装も簡単です。 AWS Organizations サービスチームのガイダンス から始め、 DenyLeaveOrganizationSCP を実装することをお勧めします。本手口に対して、最も効果が大きく、かつ最も労力の少ない制御です。それ以外にも、OU 構造全体での SCP のカバレッジを見直すこと、すべてのメンバーアカウントでルートクレデンシャルと IAM 権限が適切に保護されていることを確認すること、検知・対応プロセスが本手口を考慮に入れていることを確かめることが、より強固なセキュリティ態勢に貢献します。 Threat Technique Catalog for AWS には、根底にある手口の検知ガイダンスが含まれています。 関連リソース Threat Technique Catalog for AWS – Matrix T1078.A002: Account Root User T1078.004: Cloud Accounts T1098: Account Manipulation T1666.A002: Leave AWS Organization AWS Organizations における不正なアカウント離脱を防止するための重要なセキュリティコントロール メンバーアカウントのルートアクセスを一元管理する AWS Organizations サービスコントロールポリシー Amazon GuardDuty AWS CloudTrail ユーザーガイド 本投稿に関するフィードバックがありましたら、下のコメントセクションにご投稿ください。 著者について Shannon Brazil Shannon は AWS Customer Incident Response Team (CIRT) のセキュリティエンジニアであり、デジタルフォレンジックとクラウドセキュリティ調査を専門としています。コミュニティでは 4n6lady として知られ、セキュリティ教育と次世代の防御者の育成に情熱を注いでいます。 Derek Ramirez Derek は AWS Customer Incident Response Team (CIRT) のセキュリティエンジニアです。サイバーセキュリティと、困難なインシデントレスポンスの課題への対処を支援する AI ツールの構築という、自身が情熱を注ぐ 2 つのことを組み合わせて取り組んでいます。オースティンのダウンタウンを走ったり、ゴルフのショートゲームに取り組んだり、Dallas Cowboys を熱心に応援したりしています。 Richard Billington Richard は AWS Customer Incident Response Team (アクティブなセキュリティイベント中に AWS のお客様をサポートするチーム) のアジア太平洋地域における Sr. Security Engineer です。 翻訳は Security Solutions Architect の 松崎 博昭 が担当しました。

こんにちは、QAコンサルタントのヤマダです。 「いい感じのシステム、よろしく！」 エンジニアやプロダクトマネージャーの皆さん、顧客からこんな風に、フワッとした要望を受けて困った経験はありませんか？ 良かれと思って作ったのに「なんか違うんだよな…」と言われてしまったり。 こうした悲しいすれ違いを防ぎ、顧客の真のニーズを引き出してプロジェクトを成功に導くための強力な武器が、ビジネスアナリシスの知識体系 BABOK® (Business Analysis Body of Knowledge) です。 今回は、このBABOKの考え方を使い、ある飲食店の「漠然とした想い」を具体的なシステム要求に落とし込んでいくプロセスを、ケーススタディ形式でご紹介します。 BABOKとPMBOK：プロジェクト成功の両輪 BABOK（バボックと読みます）は、ビジネスアナリシスの専門機関であるIIBA®が策定した、ベストプラクティスを体系的にまとめた「知識の地図」のようなものです。 この話をすると、プロジェクトマネジメントの知識体系である PMBOK® (Project Management Body of Knowledge) とどう違うのか、という質問をよく受けます。この二つの違いを理解することは、プロジェクト全体を成功させる上で非常に重要です。 一言で言うと、その目的が異なります。 BABOK® (ビジネスアナリシス) PMBOK® (プロジェクトマネジメント) 目的 正しいプロダクトを作る (Do the right thing ) プロダクトを正しく作る (Do the thing right ) 焦点 What (何を作るか), Why (なぜ作るか) How (どう作るか), When (いつまでに) 役割 ビジネスニーズの発見、要求の定義 計画の立案、リソース・進捗の管理 BABOKが「そもそも何を作るべきか？」という上流工程を担う のに対し、 PMBOKは「作ると決まったものを、いかに計画通りに完成させるか？」という実行工程を担います。 例えるなら、BABOKが「目的地（＝ビジネスゴール）を定め、そこへ至るための航海図を描く」役割、PMBOKは「その航海図に基づき、船（＝プロジェクト）を安全かつ効率的に運航する航海術」と言えるでしょう。 両者は対立するものではなく、プロジェクトという船を成功に導くための「両輪」なのです。ビジネスアナリストとプロジェクトマネージャーが協力し合うことで、初めて「価値あるものを、計画通りに」届けることができます。 ちなみに、BABOKにはその知識レベルを証明する国際資格として、 CBAP® (Certified Business Analysis Professional) など、実務経験に応じた認定資格制度（ECBA , CCBA®, CBAP®）もあります。 さて、今回のケーススタディでは、特にBABOKが担う 「何を作るべきか」を定義する部分 に焦点を当てて見ていきましょう。 ケーススタディ：あるレストランオーナーの悩み クライアント: 地域で人気のイタリアンレストランのオーナー 相談内容: 「最近『ネットで注文や予約できないの？』ってよく聞かれるんだ。電話対応も大変だし、テイクアウトも強化したい。ついでに人気メニューも分析できたら最高だね。」 さあ、この「想い」をBABOKの6つのステップで具体化していきます。 実践！BABOK流・要求具体化の6ステップ Step 1: 計画とモニタリング (どう進めるか決める) いきなり機能の話をするのではなく、まずプロジェクトの進め方を決めます。 やること: 関係者は誰か、どうやって情報を共有するか、どんな進め方をするかを計画します。 具体例: 関係者: オーナー、ホール・キッチンスタッフ、常連客など 進め方: 週1でオーナーと会議。簡単な試作品を触ってもらいながら進める（アジャイル的アプローチ）。 情報共有: 議事録や資料はGoogle Driveで共有する。 Step 2: 引き出しとコラボレーション (本音と課題を聞き出す) 関係者から、言葉の裏にある本音や現状の課題を引き出します。 やること: インタビューや業務観察を通じて、関係者のニーズや問題点を深く理解します。 具体例: スタッフに現状の電話予約業務の課題（聞き間違い、予約の重複など）をヒアリング。 店舗のピークタイムの様子を観察し、業務のボトルネックを発見する。 ヒアリング結果を簡単な図や文章にまとめ、「こういうことで合ってますか？」と認識を合わせる。 Step 3: 戦略アナリシス (ビジネスの「なぜ」を掘り下げる) ここは、プロジェクトの心臓部とも言える非常に重要なステップです。単に現状の課題を洗い出すだけでなく、 「そもそも、このプロジェクトを通じてビジネスとして何を達成したいのか？」という根本的な問い（ビジネスニーズ） を定義します。 このステップを飛ばすと、いくら高機能なシステムを作っても「で、結局ビジネスの何が良くなったんだっけ？」という状態に陥りがちです。戦略アナリシスでは、主に以下の4つの視点で考えます。 現状の分析 (Analyze Current State): 我々は今どこにいるのか？ なぜ変化が必要なのか？ 将来状態の定義 (Define Future State): どこへ向かいたいのか？ 成功した状態とはどんな状態か？ リスクのアセスメント (Assess Risks): その道のりにどんな障害物（不確実性）があるか？ 変革戦略の定義 (Define Change Strategy): どうやってゴールまでたどり着くか？ 最適なルートは？ これらを踏まえた上で、今回のレストランのケースでは以下のように考えます。 具体例: 現状(As-Is): 電話対応に追われ、機会損失や顧客満足度の低下が起きている。売上データが属人的で活用できていない。 将来状態(To-Be): オンラインチャネルからの売上が30%向上し、スタッフはより付加価値の高い接客に集中できている。データに基づいたメニュー開発が可能になっている。 リスク: スタッフがシステムを使いこなせない。導入コストが想定以上にかかる。 変革戦略: まずはリスクの少ないテイクアウト機能からスモールスタートし、スタッフと顧客の反応を見ながら予約機能などを段階的に導入する。 Step 4: 要求アナリシスとデザイン定義 (アイデアを設計図にする) 理想の姿を実現するための具体的な機能（＝要求）を洗い出し、設計に落とし込みます。 やること: 要求を機能（例: 決済機能）と非機能（例: 使いやすさ）に分類し、システムの画面イメージなどを作成します。 具体例: 機能要求: メニュー表示、オンライン決済、予約カレンダー 非機能要求: スマホで使いやすいデザイン、3秒以内の画面表示 手書きのラフな画面イメージ（ワイヤーフレーム）を描いて、オーナーと「こんな感じですか？」とすり合わせる。 Step 5: 要求ライフサイクル・マネジメント (変化に強く、ブレない軸を持つ) プロジェクトを進める中で発生する要求の変更や追加に、うまく対処します。 やること: 機能に優先順位をつけ、追加要望が出た際の影響を評価し、対応を判断します。 具体例: 優先順位付け: 「オンライン決済」は必須（Must）、「クーポン機能」はできれば（Could）のように整理する。 変更管理: 「デリバリー機能も欲しい」という追加要望に対し、開発期間とコストへの影響を提示し、導入するかどうかをオーナーと合意する。 Step 6: ソリューション評価 (作って終わりじゃない、価値を測る) 完成したシステムが、本当に当初の目的を果たしているかを確認します。 やること: システム導入後の効果をデータで測定し、さらなる改善点を見つけます。 具体例: 導入前に立てた目標（KPI）である「電話対応時間を50%削減」「オンライン売上30%UP」を達成できたか計測する。 「メニューの更新が少し面倒」といったスタッフからの意見を収集し、次の改善アクション（例: 管理画面の改修）を提案する。 まとめ いかがでしたか？ BABOKのフレームワークに沿って進めることで、オーナーの 「いい感じにしたい」 という漠然とした想いが、 何を: テイクアウトと予約のオンラインシステム なぜ: 業務効率化と売上向上のため どうなれば成功か: オンライン売上30%UP といった、 誰が見ても明確で、測定可能なゴールを持つプロジェクト に変わりました。 日々の開発業務で「これ、何のために作ってるんだっけ？」と感じたとき、この6つのステップを少しだけ意識してみてはいかがでしょうか。きっと、あなたのプロジェクトを成功に導くヒントが見つかるはずです。 The post 脱・伝言ゲーム！BABOKの知識で顧客の想いをカタチにする方法【飲食店のDX事例】 first appeared on Sqripts .

こんにちは、iOSエンジニアのyamakenです。2026年4月12日（日）から14日（火）の3日間にわたり開催された、try! Swift Tokyo 2026に、LINEヤフー株式会社はGOLDス...