最初に境界を定義する
通常のクライアント デバイス、インフラストラクチャ サービス、および管理インターフェイスの役割を分離します。境界は、許可されるトラフィックが理解されている場合にのみ役立ちます。設計は、どのクライアントがどのサービスを必要とするか、どのサービスがストレージを必要とするか、どの管理者が管理アクセスを必要とするかという依存関係のインベントリから始める必要があります。
管理を慎重に行う
管理インターフェイスは、クライアント トラフィックが許可されている場所では公開されるのではなく、意図的な管理パスを介してアクセス可能である必要があります。既存のラボはリモート アクセスを使用しています。次の設計ステップは、そのアクセスがどこに入るのか、どこに到達できるのか、そして回復パスを失わずにアクセスを削除する方法を文書化することです。
ストレージの依存関係を考慮する
TrueNAS および ZFS は文書化されたストレージ環境をサポートし、Linux とコンテナーのワークロードはパス、権限、ネットワークの到達可能性に依存します。セグメンテーションの変更では、これらの依存関係を保持する必要があります。ストレージ パスまたは必要なネットワーク接続が利用できない場合でも、サービスは正常に見えることがあります。
許可されたパスと拒否されたパスの両方を検証する
将来のテスト マトリックスには、許可されるクライアントからサービスへの接続、拒否されるクライアントから管理への接続、承認される管理接続、およびサービスからストレージへのチェックが含まれる必要があります。ソースゾーン、宛先、プロトコル、期待される結果、観察された結果、ロールバックステップを記録します。これらのテストは出版計画であり、テスト結果は報告されません。
回復パスの設計
ネットワーク境界を変更する前に管理アクセスを復元する方法を文書化します。構成のバックアップ、既知のローカル アクセス方法、および明確なロールバックを伴う小さな変更により、設計のトラブルシューティングが容易になります。回復時間の結果を提示する前に、運動中の回復を測定します。
テイクアウト
セグメント化により、アクセスと依存関係を説明しやすくなります。図、アクセス マトリックス、および観察されたテスト結果は、ネットワーク ツールのリストよりも明確にそれを示します。
関連プロジェクトを探索する →