DBAとセキュリティエンジニアがリリースを止め続ける理由とその解決策
機能の準備は整っています。開発者はコードを書き終え、QAも承認し、ステージング環境も問題ありません。今夜のリリースを予定しています。
ところが、DBAが変更を見てこう言います。「このマイグレーションはテーブルを5分間ロックします。本番はその時間帯に忙しい。実行できません。」
あるいは、セキュリティエンジニアがアップロード機能をレビューし、ファイルタイプの検証もサイズ制限もなく、アップロードされたファイルに直接パブリックアクセスできることを見つけます。彼らは言います。「これはリリースできません。」
リリースは延期されます。またです。
このシナリオは、毎週あらゆるチームで繰り返されます。よくある反応は、DBAやセキュリティエンジニアをブロッカーだと非難することです。しかし、本当の問題は、彼らがどのように、そしていつ関与するかです。
後半での変更に対するDBAの問題
データベース管理者は、データベースの安定性、可用性、パフォーマンスを維持する責任があります。彼らは本番の動作を知っています。どのテーブルにトラフィックが多いか、いつ負荷がピークになるか、どの操作がロックを引き起こすかを把握しています。数百行のデータでラップトップ上でスキーマ変更をテストする開発者は、同じマイグレーションがアクティブなトランザクション下で数百万行に対して実行されたときに何が起こるかを経験していません。
DBAがリリースゲートで初めて変更を目にしたとき、彼らの選択肢は承認か拒否だけです。その機能がどれほど重要か、回避策があるか、マイグレーションをより安全なステップに分割できるかについての文脈がありません。そのため、彼らはデフォルトで慎重になります。彼らはより多くの時間を求め、別のアプローチを求めます。リリースは停滞します。
DBAはあなたをブロックしようとしているのではありません。彼らは、午前2時に自分たちが修正しなければならないインシデントを防ごうとしているのです。
セキュリティエンジニアのジレンマ
セキュリティエンジニアも同じパターンに直面します。彼らは最後の瞬間に呼ばれ、機能を渡され、迅速に承認するよう求められます。しかし、彼らは開発中にチームが見逃したものを見ます。検証されていない入力、欠落している認証チェック、露出したエンドポイント、データ漏洩のリスクです。
レビューなしで承認すれば、彼らがリスクを負うことになります。拒否すれば、彼らがブロッカーになります。どちらの選択肢も良くありません。
セキュリティエンジニアは「ノー」と言うのを楽しんでいるわけではありません。彼らは機能を安全に出荷したいのです。しかし、最後になって初めて相談されると、彼らの唯一の手段は拒否権です。彼らはそれを行使します。なぜなら、代替案は脆弱性を出荷することだからです。
根本原因：遅すぎる関与
両方の役割がボトルネックになる理由は同じです。パイプラインの最後でゲートキーパーとして扱われ、プロセス全体を通じての協力者として扱われないからです。チームは機能を構築し、テストし、その後に初めて承認を求めます。その時点では、どんな問題も手戻り、遅延、またはリスクのある例外を意味します。
これは人の問題ではありません。ワークフローの問題です。
シフトレフト：レビューを早める
解決策は、コードが書かれる前にDBAとセキュリティエンジニアを関与させることです。デプロイの準備ができてからではありません。このアプローチは、しばしばシフトレフトと呼ばれます。つまり、チェックをデリバリーフローの早い段階に移動することです。
新旧のフローの対比は明確です：
データベースの変更の場合、これは開発者が設計中に計画しているスキーマ変更についてDBAと話し合うことを意味します。DBAは次のように言うことができます：
- このマイグレーションはオンラインで安全に実行できます。
- この変更には、まずバックフィル戦略が必要です。
- このテーブルにはメンテナンスウィンドウが必要です。
- これを複数の小さなマイグレーションに分割すべきです。
開発者はコードを書く前に計画を調整します。変更がリリース段階に達したとき、DBAはすでにそれを知っており、アプローチを承認済みです。驚きも遅延もありません。
セキュリティについても同じ原則が適用されます。アップロード機能を構築する前に、チームは「この機能はどのようなセキュリティリスクをもたらすか？」と尋ねます。セキュリティエンジニアは早期にガイダンスを提供します。ファイルタイプを検証し、サイズ制限を適用し、ファイルをウェブルートの外に保存し、アクセスに認証を要求するなどです。開発者は最初からこれらを実装します。機能の準備ができたとき、セキュリティレビューは形式的なものになり、発見の場ではなくなります。
非同期にする
DBAやセキュリティエンジニアを早期に関与させることは、彼らが毎日のスタンドアップやすべての設計ミーティングに参加することを意味しません。それはスケールしません。代わりに、彼らは再利用可能な成果物を提供できます：
- DBAは安全なスキーマ変更のためのガイドラインを公開します。どの操作がオンラインで安全か、どの操作にメンテナンスウィンドウが必要か、ロック時間を見積もる方法など。
- セキュリティエンジニアは、一般的な機能タイプ（ファイルアップロード、認証、APIエンドポイント、データエクスポート）のためのセキュリティチェックリストを維持します。
- 両方の役割が、開発者がコードを書く前に質問できるオフィスアワーや非同期レビュースロットを提供します。
開発者はこれらのリソースを使用して、正式なレビューを要求する前に自己チェックを行います。DBAやセキュリティエンジニアは、エッジケースや高リスクの変更のみをレビューする必要があります。残りは確立されたパターンに従います。
実践的なチェックリスト
次のリリースの前に、これらの質問を自問してください：
- DBAは開発開始前にデータベースの変更を確認しましたか？
- セキュリティエンジニアはリスクについて機能設計をレビューしましたか？
- 安全なマイグレーションとセキュリティチェックのための文書化されたガイドラインはありますか？
- 開発者はレビューを要求する前に、それらのガイドラインに照らして自己チェックできますか？
- 最終段階のゲートだけでなく、非同期で相談するためのプロセスはありますか？
これらのいずれかに対して「いいえ」と答えた場合、あなたは次のボトルネックを見つけました。
DBAとセキュリティエンジニアは保護者であり、ブロッカーではない
彼らは本番インシデントやデータ漏洩を防ぐために存在します。それは良いことです。問題は、彼らが最悪のタイミングでその仕事を強いられることです。早期に関与させれば、彼らはリリースを止めることなく、導き、助言し、保護することができます。遅く関与させれば、彼らにはリリースを止める以外の選択肢がありません。
タイミングを修正すれば、ブロッカーは消えます。