「バスにひかれた」場合に備えて、ビジネスクリティカルなシークレットに緊急アクセスを設定するにはどうすればよいですか？
私は中小企業の主要な開発者およびIT管理者として働いています。何らかの事情で急に利用できなくなっても、事業が継続できるようにしたい。私が行うことの多くは、（キーベースのsshを介して）多数のサーバー、クラウドサービス、およびアプリケーションの他の安全なインフラストラクチャへのアクセスを必要とします。これらのサービスの一部は、専用のMFAアプリ（Amazonなど）またはSMSを使用してMFAを使用します。
「バスでの攻撃」計画とドキュメントが完全で包括的なものであることを確認するにはどうすればよいですか。このドキュメント自体がセキュリティリスクではないことを確認するにはどうすればよいですか。
ドキュメントは、VPNの背後にある共有ファイルサーバーでホストされますが、「DropBox」のようなインターフェースをベースファイルサーバー（認証、デスクトップ同期、ファイル）の上に配置するサードパーティのWebフロントエンドを使用してアクセスすることもできます。共有など）。ファイルは、私と他のファイルサーバー管理者だけが表示できる場所にあります。
このドキュメントの「秘密」（パスワード、秘密鍵、MFAアクセス）を管理して、セキュリティを損なうことなく包括的であることを保証するにはどうすればよいですか？
私のアドバイスは、ドロップボックスから秘密を削除し、別の場所に保管することです。指示は誰でも簡単に読めるようにする必要がありますが、データの適切に保護された部分にアクセスする方法に関する指示を含めることができます。これにより、アクセシビリティ側とセキュリティ側を分離できます。
自分でセキュリティについて考えることができたら、これらのキーを保護するためにどれだけ必要かという本当の質問をすることができますか？これはビジネスロジックの問題なので、経営陣に相談してください。あなたは：
- 誰もが知っているファイルへのパスワードを持っている
- 各個人が自分のコピーを保持できるように、複数のパスワードを設定したファイルを用意します。
- M-out-of-Nアルゴリズム（金庫のロックを解除するために2つのキーを必要とするデジタル版）によってファイルをロックします。
- ファイルのロックを解除する個人のグループに関係なく、1つの「マスター」パスワードを必要とするM-out-of-Nアルゴリズムを使用し、1つのマスターは、時々チェックする不正開封防止金庫に物理的に保管されます。
ここで創造性を使用してください。 何をするにせよ、「指示」と「機密情報」を分離することで、情報を適切に保護し、後でそのデータを取得する方法に関する指示を提供することができます。
ビジネスロジックの決定には、稼働時間に関する質問も含まれます。あなたの人生に何か問題が発生した場合、ビジネスに影響が出るまでに、別の管理者があなたの仕事を引き継ぐ必要がありますか？サーバーに問題が発生した場合に、これらの指示と機密情報をどの程度適切に複製するかを検討してください。サーバーを管理していて、バックアップから復元する方法の手順を保存する必要があったとき、サーバーの独自のwikiを使用してその情報を保存し、簡単に表示できるようにしましたが、明らかに、グリッチのシナリオではそれほど役に立ちません。そのマシンのdev VM=にコピーがあり、3つの別々のPCにそのコピーを保存し、プリントアウトしました。プリントアウトが最新の状態に保たれることを保証できませんでしたが、がんばります。
これは、バス計画のヒットの一部とは限らないものも指摘しています。それは、優雅な低下です。バスでヒットするシナリオのすべてがバスにヒットすることを含むわけではありません。中には、不幸なことにアクセスできない状態に陥っている人もいます。いくつかは、あなたが会社を辞めることを含みますが、1〜2つの質問に答えることができます。その他...しないでください。計画を階層化することを検討してください。小さな事故は非常に適切に保護されている可能性がありますが、大きな事故が発生してもビジネスの損失につながる可能性があります。例として私のバックアップ復元計画を使用するために、印刷されたバージョンが完全に最新でないことがほぼ保証されました。しかし、稲妻が街区のすべてのコンピューターを一掃したとしても、何もないよりはずっと役に立ちました。一方、サーバーにハードドライブがあり、バックアップから復元する必要がある場合、開発ボックスで同期を維持したバージョンはほぼ確実に最新のものでした。
この失敗の例：私はKERBEROSが管理者によって管理しているネットワーク上のユーザーであり、他人に不信感があり、バスでヒットする計画を持っていませんでした。彼が去ったとき...私たちは彼のサーバーを破壊しようとするハッキングパーティーがありました。結局のところ、私たちの最も即興的なバス当たりの計画は、マシン（それらのすべて）をワイプして、ゼロから始めることでした。これは最良の計画ではありませんでしたが（実際、私はそれが最悪の計画だと思いますか？）、ビジネスは動き続けました。約2日間停滞し、不機嫌な顧客がたくさんありました。フランクハーバートのDuneの言葉では、「スパイスは流れなければなりません」。最悪の場合でも（サーバーのハードドライブがバスから投げ出され、頭をぶつけて、バスでヒットする計画のすべての記録を破壊するという奇妙な事件が発生する可能性があります）、ビジネスdoesは動き続ける方法があります...しかし、私はそれより少しだけバーを上げようとすることを承認します！
USBデバイスを入手します。すべての秘密をUSBに、できればKeePassファイルに入れます。ドキュメントで、USBの場所とロックを解除する方法を新しい人に伝えますが、デバイスを所有者のオフィス、会社の金庫、安全なデポジットボックスなどの安全な物理的な場所に置きます。公開し、他の従業員の詮索好きな目から離します。
この計画の利点は次のとおりです。
- インターネットまたは内部ネットワーク上にありません
- 新しい従業員が、保管場所の担当者に本物であることを少なくとも納得させることができたと確信することができます（おそらく、高位の従業員があなたの保管場所に近づくことさえあります）。
- 誰かがあなたより前にフラッシュドライブにアクセスしようとする場合、ええと、ことわざのバスに見舞われるとき、誰かがおそらく「うーん、アンドリューはまだ生きている。なぜ誰かがこれに触れているのだろう」と考えるべきでしょう。
- 誰かがあなたの文書を見つけた場合、彼らが行うことができる被害の量は制限されます（特に、彼らがインターネットを介して侵入できた場合-あなたの情報を得るために出張する人はほとんどいません）。
グッズを見つけるには、1）書類、2）物理的なアクセス、3）「フィヨルドを固定」する必要があります。 USBはまた、次の人のためのきちんとした小さなパッケージです-プラグアンドプレイ！または、あなたが会社にとってどれほど重要であるかに応じて、パニックになります。
「緊急用のみ」のアカウントを作成する
ほとんどのシステムでは、日常の管理で使用されるある種の特権アカウントがあり、それらは組織のポリシーに応じてパーソナライズされる場合とされない場合があります。
資格情報については、さまざまな理由でそれらにアクセスできなくなる可能性があります-バスに当たったことを知っている人によって、またはその資格情報の意図された安全なストレージを失うことによって（たとえば、火事でコンピューターを失うこと）、または何らかの方法で管理することによってパスワードを知らないものに変更するなど.
役立つ可能性があるのは、完全なアクセス権を持つが、日常的な使用を目的としたものではない主要なシステム用に個別のアカウントを作成することです。これは以下を意味します：
- 現時点では、誰もそれらにアクセスできません-必要なパスワードを知っている人はいません。
- 誰かがそれらにアクセスする場合は、誰にでも通知する必要があります（通常の状況では発生するはずがないため）。たとえば、ログイン時に複数の主要ユーザーにメールを送信する自動化スクリプトでは、それらのアカウントからのすべてのアクションがログに記録され、これらのアカウントから何かが実行されると毎日の監視が点灯します。
- 必要に応じて、人々はこれらのアカウントにアクセスできます。簡単な方法は、長いパスワードまたはキーを生成し、印刷して、封印および署名された封筒に入れ、金庫にロックすることです。
そこにバックアップ手順と資格情報を置きます
手順、バスごとの計画、および二次資格情報のリストを都合のよい方法で維持する場合は、これらのドキュメントまたはパスワードデータベースが緊急用アカウントからもアクセスできることを確認してください。
多分あなたの状況へのより良い解決策は、たとえあなたがバスに当たったとしても、あなたの資格が永久に失われたとしても、悪いことが起こらないようにシステムを設計することです。
おそらく、問題をauthenticationとauthorizationの2つの問題と考えるのが最善です。
認証により、あなたが本人であることを証明します。一部のシステムでは、自分の資格情報を持つ誰かしかリクエストを行うことができなかったため、それが本当に自分からのリクエストであることがわかり、あなただけ資格情報を知っています。
承認は、あなたが特定のことを行うことが許可されていることを確立します。リクエストは本物である可能性がありますが、許可されていません。
少なくとも2人が許可されている場合、そのうちの1人がバスに当たっても問題はありません。アリスはバスで殺される可能性があり、彼女の資格の知識は永遠に失われます。しかし、ボブは自分の資格を知っており、アリスができることは何でもできる権限を持っています。
システムが文字通りバスにぶつかって殺されるような方法で設計されている場合、それはまた、一人の資格を取り消すことが可能であることを意味します。元従業員、特に悪口を残している従業員は、セキュリティ責任です。元従業員にパスワードを忘れさせることはできないため、安全のために、従業員が退職するたびにすべての共有パスワードを変更する必要があります。実際には、これは非常に面倒であり、行われません。そもそもパスワードを共有しないことで問題は解決します。
パスワードを共有しないと、説明責任も保持されます。管理者がいない状態でビジネスを運営することはできませんが、特定の管理者が自分の権限を悪用しているかどうかを確認する機能が必要です。最終的には、終了または訴訟の脅威により、管理者は虐待から解放されます。パスワードが共有されている場合、「パスワードを持つ他の管理者の1人でなければなりません」がもっともらしい防御策です。
時々、パスワードの共有を避けることが不可能に思われる状況に出くわします。しかし、すぐには明らかではない場合でも、通常は解決策があります。
Rootパスワードを共有する必要がありますか？いいえ、ルートパスワードはまったく使用できません。代わりにSudoを使用してください。
AWSルート認証情報はどうですか？代わりにIAMを使用できます。
たぶん、あなたは避けられない、特に頭の痛いWebアプリケーションを持っているでしょうか？これを修正することはできないかもしれませんが、カバーすることはできます。複数のユーザー間で資格情報を共有できるパスワードマネージャを使用してください。 （LastPassがこれを実行できることを知っています）。パスワードを共有している間に、少なくともパスワードを変更して新しいパスワードの知識を配布する自動化された手段があります。少なくとも従業員が退職するたびに、できればより頻繁にパスワードを変更します。
ここでの回答のほとんどは、おそらくOPでのこの明示的な質問が原因で、資格情報の処理に関連しています。
このドキュメントの「秘密」（パスワード、秘密鍵、MFAアクセス）を管理して、セキュリティを損なうことなく包括的であることを保証する最良の方法は何ですか？
しかし、タイトルは別の質問をします。
バス計画による安全なヒットの開発
それの答えは自動化です
Devopsでは、ポジションのサーバー側のほとんどが2つのカテゴリに分類されます。
インフラストラクチャを修正します：通常、自動化するものはありません。問題はそれぞれ異なります。これらの場合、インフラストラクチャ（サーバー、ネットワーク、開発者がGitリポジトリとどのように相互作用するか）に精通していることが重要です。
インフラストラクチャを維持します：新規作成VMインスタンス、設定 Apache 、開発アクセスを有効化リソースなどへこれは自動化が最も目に見える場所です。
後者における自動化の役割は明白であり、前者の問題を正常に解決するための鍵は、後者の自動化です。自動化されたPythonおよびBashスクリプトは、生きているドキュメントとして機能し、期待されるものサーバーとネットワークの：ワークフローが変更されると、変更されるのはスクリプトです。Gitは古いサーバーに適用可能な変更を記録し、git commitメッセージは明示的です。
これは、それ自体を行う方法に関する別のアイデアではなく、まだ議論されていないが非常に重要な何かにフラグを立てるためのポイントです。私はこれらの秘密が本当にビジネスに不可欠であるという見地から進んでいます。
テスト。
いくつかの災害復旧シナリオが想定されています。単純なものもあれば、より複雑なものもあります。複雑さが増すほど、テストする理由が増えます。この問題は、ビジネスクリティカルな環境でシーンから「削除」されている人をどのようにテストするかから発生しますか？クリスマスの取引中に生産サーバーを20mmの円形に配置し、主要なIT担当者と連絡を取り合うのは、おもちゃ工場のボードを通り抜けるのが難しいでしょう。これが取締役会が直面しているジレンマです。それが重要な場合は、テストする必要があります。テストすることはあまりにも重要ですか？
簡単なことがあなたを引き付けるでしょう。金庫にデータを入れることについて言及した人もいます。すごい。多くの人は、金庫を人から離れた地下に保管しています。また、軽微な火事によって最初に水が満たされる場所でもあります。別の;あなたの危険な給与担当者はあなたの給与で本当に危険なことをしています。警察が入り、その後の調査のためにすべてのサーバーを没収します。それらを取り戻すには1年かかります。目を転がさないでください-起こります。
ビジネス継続性はかなり確立された技術なので、NASA、グーグル、バークレイズ、軍隊、原子力発電所が行うことを実行するだけです。冗長性を持たせます。アンドリューと言って申し訳ありませんが、このシナリオでは、あなたが会社にとっての主要なリスクです。ボードはこれを認識させる必要があり、あなたとあなたの少なくともいくつかのキットは（複製の意味で）冗長にする必要があります。
それまでは、運用責任者に重要人物保険や事業継続保険を取得してもらいます。
私は、さまざまなプラットフォーム上に散在し、緩やかに関連付けられたカスタムソフトウェアを数多く持つ中規模企業の唯一のIT管理者と非常に似た状況にあります。それよりひどいのは、POSシステムからオンライン予約、自作のCMS、従業員トレーニングソフトウェアなど、過去10年間に会社のためにすべてのソフトウェアを書いたことです。現時点で私が理解しているのは、私だけです。それらの情報源を見さえしました。会社が成長するにつれ、バスにぶつからないように何度も頼まれました。これに対する私たちの解決策を教えてあげましょう。
混乱が生じることを理解してください。期待を管理します。会社があなたが知っているすべてを学ぶために多分多給の人を雇うことを望んでいない場合、彼らは緊急時に参入する必要がある人にとって非常に急な学習曲線があることを期待する必要がありますあなたの靴を埋めてみてください。これは、ドキュメントがどれほど優れていても当てはまります。
サービス請求書があなたではなく会社に送られることを確認してください。
ビジネス文書の継続性。ある時点で、会社のCEOが正確に私たちが持っているサーバー、各サーバー上にあるもの、各ソフトウェアが何をするか、そしてそれらのパスワードを読むことができる、英語でレイアウトされたドキュメントを書くように求められましたアカウント。その中には、一緒に来てそれを実行し続ける必要がある人のためのメモとヒントがあります。ただし、（1）に従って、すべてのソフトウェアの機能、既知の問題と制限、および構造を詳細に説明するには、本が必要であると理解されています。したがって、このドキュメントには必要最低限のものが含まれています。誰かがコードに入ると、cronタスクの確認とコメントの読み取りを開始し、それがどのように機能するかを理解できるようになることを期待しています。
必要に応じて継続性ドキュメントを更新し、PGPで暗号化して、会社のCEOと私だけが開けるようにし、Webサーバーで彼が知っているアドレスにアップロードします。 CEOは、PGPキーを安全に保つ責任があります。これですべてです。
そして、耳を傾けてください-彼らがあなたが死んだ後もあなたをリラックスさせるつもりがないなら、それは昇給を求める時です。