データをシステムから分離する: 設計による不変性
目次
大半の組織はまるでサーバこそが価値あるもののように保護します。イメージを作り、バックアップし、不安げにパッチし、一つが死んだり侵害されたりすると元のままに戻すのに時間を注ぎます。その間データ、本当に価値のある部分は、同じサーバ上でサーバが偶然受けた程度の保護の中に住んでいます。
その関係をひっくり返せば多くのセキュリティが簡単になります。システムは使い捨て、データは宝物として扱う。サーバをコードから作り、数日の復元ではなく数分の交換にします。それから本物の保護努力をあるべき場所へ集中させます。データ自体、生涯を通じて追跡され、意図的にバックアップされ、ますます処理するシステムですらなくどこか別の場所に置かれるものです。
修復ではなく再配布されるシステム #
旧モデルはサーバをペット扱いしました。各々に名前と性格と誰も完全記録していない手動修正の歴史があります。ペットサーバが死ぬと復元は考古学です。記憶とメモと希望から数年分の変更を再建します。
現代モデルはトレンドより長生きしたDevOpsの言葉を借りて、サーバを牛群扱いします。病み果てた牛を蘇らせません。取り替えて先へ進むのです。実務ではこれを意味します:
Infrastructure as code. あらゆるサーバ・コンテナ・構成が宣言的に定義されます。プラットフォームにはTerraform、ホストにはAnsibleやcloud-init、ワークロードにはコンテナイメージ。走っているインスタンスはその定義の一実体にすぎず、他と区別がつきません。
不変デプロイ。 サーバへログインして変えたりパッチしたりする代わりに、新しい版を作り、試験し、ロールアウトして古いインスタンスを丸ごと入れ替えます。何も積み上がりません。手作業変更の静かな蓄積が環境を独特で説明不能にする構成ドリフトが、構造的に不可能になります。
復元ではなく再展開。 人を驚かせる報酬がここにあります: 正しく築いた牛群艦隊はほとんどバックアップを必要としません。サーバが侵害されようが壊れようが失われようが、復元しません。コードから数分でredeployします。定義こそバックアップだからです。回復の会話が「この機械をどう戻す?」から「代替をどれほど速く上げられる?」へ変わります。実際の事件中ずっと良い会話です。
ランサムウェア表面も劇的に縮みます。暗号化が害するのは再生しがたいものだけです。Gitリポジトリから作られる使い捨て機械の再生は安いのです。
注意のすべてがデータへ移る #
システムが使い捨てになれば、代替不能なすべてはデータの中にあります。それは独自の規律を受ける値打ちがあり、ほとんどの組織が正確に答えたことのない問いから始まります。私たちはどのデータを持ち、どこに住み、誰が触れ、時間とともにどうなるのか?
ライフサイクル全般でデータを追跡。 作られ、処理され、複製され、保管され、破棄される: 各段階が知られていて意図的であるべきです。ライフサイクル追フサイクル追跡は幾度も報酬を払います。PDPA等が機械でなくデータに従うため規制義務がどこに付くか教えます。誰も勘定していない忘れた複製、漏えいが本当に起こる場所を露呈します。そして今日消せるものを教えます。多くの場合最も安いリスク低減です。存在しないデータは漏れません。
機械を無意識にではなく、データを意図的にバックアップ。 システムがコードで定義されればバックアップは集中し正直になります。DBダンプ、オブジェクトストレージ複製、設定リポジトリ、シークレット保管庫。ゴミまで含む毎晩の全体イメージではなく、本当に重要な事柄の小さく検証可能な集合です。
データを処理システム外に置くことを検討してください。 アプリケーションはローカルにほぼ何も持てます: stateは管理型databaseへ、fileはobject storageへ、secretはvaultへ。処理層には盗む価値がなく、侵害されたapplication serverは報告義務事象ではなく運営の厄介者になります。おまけに保存専用設計のデータサービスはversioning、不変オプション、粒細かなaccess controlなど、どんな汎用サーバも到達できない強い内蔵保護を通常備えます。
三つではなく一つの艦隊を運航 #
この内にもう一つの単純化が隠れています。艦隊そのものについてです。Windows-Linux混合estateを運ぶ組織のコスト構造を見て重複を数えてください:
- 二つの技能セット。 Windows管理とLinux管理は別職業です。両方支援は各専門家採用か両方浅い受容を意味します。ざっくり、同じ台数に二倍のチーム。
- 二つのtoolchain。 パッチング、監視、構成管理、ハードニング基準、agent配備: 各々が二つ存在し、それぞれ個別にライセンス、維持、更新されます。倍予算、管理基盤の倍攻撃面、静かに遅れ取れるものも倍。
- 二つの失敗様式。 インシデント対応プレイブック、フォレンジック能力、災害復旧手順が全部プラットフォーム別に分岐します。事件中その分岐がちょうどあなたにない時間を食います。
航空会社の類推がここで効きます。成功した会社であらゆる機種を飛ばす所はありません。機種追加ごとに整備計画、予備部品在庫、乗員資格、訓練パイプライン、格納庫装備が掛け算され、その費用は購入決定が記憶から消えた後も永遠に繰り返されます。だから航空会社は路線に奉仕する最小機種集合へ無慈悲に標準化します。IT estateも同じ算数を受け取る価値があります。標準OSを選び、その線を守れば、すべての「二」が「一」になり節約は年々複利です。
標準化はセキュリティも直接強めます。一体制は深く理解された一つのハードニング基準; 調整済み信頼できる一本のパッチpipeline; 実estateに合う一セットの検知規則を意味します。毎回、深さが被覆に勝ちます。
どこから始めるか #
- ワークロード一つを選び使い捨て化。 手触りの設定が一つもなく完全交換が数分になるまでコードから組み直してください。
- データを正直に棚卸し。 どこに、どのシステム上に、だれの支配下にあるか、明日消せるのは何か。
- stateをアプリケーションサーバ外へ適切なaccess controlと不変オプションを持つ専用storageへ。
- 艦隊分割コストを正直に計算。 複製されたlicence、tool、人員を統合価格と比べます。航空会社が路線を評価するように経営層へ提示: 反復費用対反復収入。
- 今後の標準設定: 新システムは標準艦隊へ参加、code-defined、可能な限りstateless。例外には書かれた理由が必要。
関心事の分離はengineering最古の教訓の一つであり、securityは文字通り適用して恩恵を得られます: systemは仮、dataは恒久、各々を本当の本性に応じて守る方が両方を下手に守るより安いのです。
弊社の構成・アーキテクチャ評価が dataの所在対処理場所をmapし分離道筋を設計し、 Linux hardening practiceが standardisationを実らせるsingle-fleet baselineを築きます。または schedule an Engineering & Scoping Sessionでteamとともに計画を。