共有パスワードがゼロだったセキュリティ監査

質問票は42行のスプレッドシートの添付として届き、そのうちの1行がアカウントディレクターを凍りつかせました。「認証情報の管理と、アクセスの付与および取り消しのプロセスを含め、当社の広告アカウントへのアクセスがどう管理されているか記述してください。」この顧客がこれまで取引したほとんどのエージェンシーにとって、その単一の質問こそ、会話が気まずくなる場所でした。これは異なる結末の物語です。このagency security audit shared ad account passwordsでは、共有の広告アカウントパスワードこそレビュアーが精査しようと探したものでしたが、1つもありませんでした。エージェンシーはポリシーの強さではなく、アーキテクチャの形によって合格したのです。

これは、エージェンシーがミッドマーケットやエンタープライズの顧客に売り始めると一般的になるパターンから描いた複合的な物語です。名前と正確な詳細は説明用です。失敗のモードと、それを回避するアーキテクチャは本物です。

質問票：調達が誰がアカウントに触れられるかを尋ねる

エージェンシーは普段より大きな顧客、つまり本物のセキュリティ機能を持つ資金調達済みの消費者ブランドを獲得したばかりでした。契約が締結される前に、調達はベンダーセキュリティ質問票を送りました。かつてはソフトウェアベンダー専用だった種類の文書が、今や規制されたブランドのアカウントやデータに触れるあらゆるエージェンシーに届きます。その中に埋もれていたのは、広告エージェンシーがプロのパートナーに見えるか負債に見えるかを決める質問でした。あなたのチームの誰が当社の広告アカウントにアクセスできるか？そのアクセスはどう付与されるか？誰かが去るときどう取り消されるか？認証情報は共有されているか？あなたのチームが変更したことの記録はあるか？

アカウントディレクターの最初の本能は、ほとんどのエージェンシーリードが持つ本能でした。慎重な答えを下書きし始めること。パスワードマネージャーを記述し、オフボーディングのチェックリストを説明し、チームが規律正しいことをレビュアーに保証する。しかしエージェンシーのオペレーションリードはその下書きを止めました。ディレクターがまだ十分に理解していないことを彼女は知っていたからです。エージェンシーが実際に働く方法を考えると、それらの質問への正直な答えは、まったく安心できるものではありませんでした。それらは、うまくいかない可能性のあることのリストでした。

なぜほとんどのエージェンシーはアーキテクチャではなくポリシーで失敗するのか

ここに罠があります。「アクセスはどう管理されているか」に対する標準的なエージェンシーの答えは、共有認証情報の上に重ねられた一連のポリシーです。エージェンシーは顧客のMetaログインをパスワードマネージャーに保持し、複数人が2FAプロンプトを通過できるよう2要素シードを文書化し、認証情報をチャットに貼り付けないというルールを保ち、バイヤーが去るときに誰かがパスワードのローテーションを覚えているようオフボーディングのチェックリストを維持します。

それらの一つひとつが約束であり、すべての約束は失敗する場所です。パスワードマネージャーは、エントリにアクセスできる人々と同じだけしか安全ではありません。文書化された2FAシードは、認証アプリを離れた瞬間に2FAの目的全体を打ち負かします。オフボーディングのチェックリストは、それがスキップされる1つの忙しい週まで機能します。私たちは以前、共有ログインがエージェンシーを静かに殺す運用上の仕組みについて書きました。セキュリティレビューは、同じ共有ログインが、顧客の前で、紙の上で、エージェンシーを商業的に殺す場所です。

オペレーションリードは、まさにこのステップでエージェンシーが取引を失うのを見てきました。レビュアーが顧客のパスワードを知る人々のリストを求め、エージェンシーがそれを提示し、会話がローテーションスケジュールと保管庫の権限についての交渉に変わります。エージェンシーが負けるしかない交渉です。根底の事実が決して変わらないからです。人間が顧客の認証情報を保持しているのです。

アーキテクチャの答え：System-Userトークン、監査すべき共有ログインなし

エージェンシーはアクセス管理の質問に1段落で答え、その段落はポリシーではなくアーキテクチャを記述しました。エージェンシーは顧客のMetaログインを保持も共有もしません。顧客のビジネスをSystem-Userトークン、つまりサーバー間の認証情報を通じて一度接続し、そのトークンから運用レイヤーがビジネス識別子を介して接続された広告アカウントを自動的に検出します。メディアバイヤーは決して顧客のパスワードを受け取りません。バイヤーが個人または共有の認証情報で顧客のアカウントにログインする時点が存在しないからです。彼らはエージェンシー自身の内部アクセスレイヤーを通じて働きます。

その単一のアーキテクチャ上の選択が、質問票が探るために作られた質問のカテゴリ全体を溶かします。保存すべき共有パスワードがないので、保管庫から漏れるものがありません。文書化された2FAシードがないので、打ち負かされる第2要素がありません。バイヤーが去るときにローテーションすべき認証情報がありません。誰一人としてそれを保持したことがないからです。レビュアーは、他のすべてのベンダーの答えが明らかにした共有認証情報のリスクを探しましたが、このエージェンシーには見つかるものが何もありませんでした。エージェンシーが慎重だったからではなく、危険なオブジェクトがそのワークフローに存在しなかったからです。これは、個別ログイン対本物の運用レイヤーのガイドにある運用上のポイントのアーキテクチャ上の対応物です。運用レイヤーこそ、1つの接続が認証情報を決して配布することなく多くのバイヤーに役立つことを可能にするものです。

内部RBAC：ロールで付与され、取り消し可能、スコープされ、ログ化されたアクセス

管理すべき共有パスワードがないため、アクセスの質問は、セキュリティチームが実際にそれを求める場所、つまりエージェンシー自身のロールベースのアクセス制御の内部へと移りました。各バイヤー、ストラテジスト、アカウントリードは、定義されたロールを持つ名前付きシートを持っていました。アクセスはロールを割り当てることで付与され、ロールが必要なアカウントとアクションだけに到達できるようスコープされ、シートが削除された瞬間に取り消されました。パスワードのローテーションも、慌てふためきも、誰かの記憶への依存もありません。

これは、エージェンシーが犯す権限の間違いについての記事にカタログ化された失敗モードの構造的な対極です。アクセスが共有パスワードのとき、それを狭く付与できず、きれいに取り消せず、誰が持っていたかを証明できません。アクセスが名前付きシート上のロールのとき、3つすべてが些細になります。レビュアーは去っていく従業員のアクセスがどう削除されるかを尋ねました。答えは「彼らのシートを削除すれば、アクセスもそれとともに終わります」でした。彼らが去った後も循環し続ける共有の秘密がないため、追加の質問を必要としない文です。

証拠としての監査証跡：誰が、いつ、何を変えたか

質問票の最後のアクセスの質問は、エージェンシーが最も恐れるものでした。あなたのチームが当社のアカウントで変更したことの記録はあるか、です。共有ログインでは、正直な答えはノーです。ネイティブの履歴はすべての変更を同じ共有所有者のアイデンティティで刻むため、編集を人に帰属させる方法がありません。このエージェンシーの答えは画面でした。すべてのローンチ、予算変更、一時停止、クリエイティブ編集が運用レイヤーを通じて実行されたため、それぞれが自動的に捕捉され、それを行った名前付きシートに、タイムスタンプとともに、顧客が運用するすべてのプラットフォームにわたって帰属されました。

その監査証跡は二重の役割を果たしました。セキュリティレビューに対しては、変更記録の質問に率直に答えました。はい、すべての変更が帰属されタイムスタンプされ、タイムラインがこちらです。エージェンシー自身の運用に対しては、なぜ広告アカウントには本物の監査ログが必要かで説明した同じ説明責任の記録でした。「誰かが入札を調整したと思う」を「このバイヤーがこの時刻にこの変更を行った」に変えるものです。レビュアーは、クリーンで帰属された変更ログを成熟したベンダーの兆候として扱いました。実際そうだからです。誰が、いつ、何をしたかを正確に示せるエージェンシーは、尋ねられる前に説明責任について考えてきたエージェンシーです。

単一のアクセスポリシーを書き直すことなくレビューに合格する

結果の最も印象的な部分は、エージェンシーがしなかったことでした。この契約のために新しいアクセス管理ポリシーを書きませんでした。このセキュリティ意識の高い顧客のために特別なプロセスを立ち上げませんでした。より頻繁に認証情報をローテーションすることも、保管庫のエントリを保持する人を制限することも約束しませんでした。すでに働いていた方法、つまりSystem-Userの接続、ロールベースのシート、帰属された変更ログを記述することで質問票に答え、その記述がコンプライアンスでした。

それが、手続きではなくアーキテクチャによってセキュアであることの静かなてこです。手続き的なセキュリティは、すべての監査のために実行され、文書化され、再実行されなければならず、注意が途切れた瞬間に劣化します。アーキテクチャ的なセキュリティは、誰かが見ているかどうかにかかわらず保たれるシステムの特性です。エージェンシーは、いくつかの段落を書きアクセスレイヤーのスクリーンショットを共有するのにかかる時間でレビューに合格しました。合格する仕事は、そもそも認証情報を配布しないことを選んだ何年も前に行われていたからです。

「アーキテクチャによってセキュア」が質問票を超えて勝ち取るもの

締結された契約は明白な賞でしたが、アーキテクチャは取引が成立した後も報い続けました。1つの顧客の調達チームを満足させたのと同じ設定が、追加の作業なしに次の顧客を満足させ、それはエージェンシーがセキュリティ意識の高いアカウントを、それぞれを特別なケースとして扱うのではなく市場として追求できることを意味しました。すべての将来の質問票が、同じ準備された答えに出会いました。

それはまた、エージェンシーの内部のリスク姿勢を変えました。バイヤーが去ることは、十数の顧客アカウントにわたる認証情報ローテーションの非常事態ではなく、非イベントでした。シートを削除すれば終わりです。帰属された変更ログは、内部の引き継ぎが最近の変更の完全なマップとともに来ることを意味しました。そして共有の秘密の不在は、エージェンシーの単一最大の侵害面、つまり顧客のログインでいっぱいの保管庫が、侵害される対象として単に存在しないことを意味しました。質問票を勝ち取ったアーキテクチャは、顧客のために管理した6つの広告プラットフォームすべてにわたって、どんな普通の日にもエージェンシーを傷つけにくくしたものと同じでした。

教訓：最強のセキュリティの答えは、告白すべき危険なことが何もないこと

後で何が違いを生んだのかと尋ねられて、オペレーションリードは率直に言いました。エージェンシーは、危険なものを管理することに長けていたからセキュリティレビューに合格したのではありません。管理すべき危険なものを持っていなかったから合格したのです。保護すべき共有パスワードも、管理すべき2FAシードも、ローテーションすべき認証情報もありませんでした。バイヤーが顧客のアカウントに到達する方法が、それらのどれも決して含まなかったからです。

それが、真剣な顧客に売るあらゆるエージェンシーが吸収すべき原則です。アップマーケットに移るにつれて、セキュリティ質問票はときおりの驚きであることをやめ、日常的なゲートになり、それが本当に尋ねている質問は常に同じです。あなたが当社のアカウントを扱う方法のどこにリスクがあるか、です。共有ログインの上に築かれたエージェンシーは、その質問に緩和策のリストで答えなければならず、その一つひとつが失敗しうる場所です。System-Userトークン、内部のロールベースのアクセス、帰属された監査証跡の上に築かれたエージェンシーは、それにアーキテクチャで答えられます。そして「リスクはどこか」への可能な限り最強の答えは、告白すべき危険なことが何もないものだと判明します。このようにエージェンシーを運営するプレイブックの残りは、エージェンシーツールハブをご覧ください。