情報セキュリティ基本情報

InfoSecの主な目的は何ですか。

コンテキスト境界でのすべての変更が適切に規制されるようにするため。

たとえば、UNIXプラットフォーム上のすべてのシステム・コールは、UNIXユーザー/グループprocess+filesystemセキュリティ・モデルに関してこの条件を満たします。コンテキスト・スイッチのリテラル定義(システム・コールによって入力)には、カーネルに対するAPI使用状況の妥当性チェックが含まれます。’電話の側。

SaaS納入の観点から、ランタイムUNIX システム・コールからのすべてのデータはtaintedとして扱われる必要があります、およびアプリケーションへのイングレス・ポイントで検証’sアクセス可能なプロセス・メモリー。このようなアプリケーション・データについては、これらのイングレス・ポイントをinfosecコンテキスト境界と見なす必要があります。適切な規制検証では、文字列パターンをホワイトリストに登録する必要があります(通常はregexを使用)。taintedホワイトリストとその依存データをクリアするデータは、別のシステム・コールを介して、アプリケーションのプロセス・メモリーから安全にアウトバウンドに出荷できます。これらのシステム・コールエグレス・ポイントもinfosecコンテキスト境界です。”コンドーム” イングレスtaintedデータのホワイトリスト・パターンは、エグレス・ポイント上のこれらの特定のAPIによって通知されます。SSDLCでは、対応するホワイトリストと同様に、これらのエグレス・ポイントが進化します。

UNIXセキュリティ・モデルだけでは、ネットワーク・クライアント/サーバー・アプリケーション開発のための規定は設けられていません。なぜなら、これまで、90s(Sun Microsystems)におけるネットワーク・コンピューティングの台頭前のBSDソケットAPIは、UNIXの誕生後10年以上(OSベースのマルチユーザー・セキュリティ・モデルが誕生時に完全に形成されて)発明されたからです。MITカーベロ これは正しい方向へのステップでしたが、SaaSコンテキストでは多くのことが望まれます。

一部のユーザーにかわってカーネルレベルの作業を実行するためのCPUの安全なスケジューリング”承認済ユーザー/グループ/ロール・コンテキスト” 基礎となるプロセスに連結されない’UNIXユーザー/グループコンテキストは、常にUNIXモデル外です。多くのinfosecイニシアチブは、この規制責任がアプリケーションのみに属していることを認識していません。’「Let yours be one!

この場合’現時点では、DevOps/SREチームがSaaSセキュリティ(CAI)のインシデントに精通していることは明らかではありません。htop‘s 売春婦 インターフェースs キー! 『Better Still Master』売春婦 スタンドアロンとして。(FYI: githubにこれらのバイナリの静的コンパイルがあり、SSH/SSM配信を含むK8sコンテナまたはノードに配信できます。https://github.com/joesuf4/home/tree/wsl/bin).

これは、実用的問題として、ゼロトラスト・イニシアチブにどのように関連しますか。

ゼロトラスト・アーキテクチャ ネットワーク固有のinfosecコンテキスト境界がありません。

VPN/ファイアウォールのコンテキストが実際に存在する場合もありますが、これらの詳細はゼロトラスト・フレームワーク内のInfoSecに関連していません。つまり、このようなネットワーク・トポロジ・セキュリティ・イニシアチブは、ゼロトラスト・イニシアチブを増強する可能性がありますが、アプリケーション・レベルを上回るベース・サーバー・ホスト・セキュリティ・レベルでのゼロトラスト・イニシアチブに依存することはありません。

たとえば、MIT KerberosとActive Directoryはゼロトラスト準拠です。