Orionのセキュリティ

“不明瞭さによるセキュリティは、あまりセキュリティではありません。”

American locksmithの発音をAlfred Charles Hobbs 1851年、ロンドンの展覧会でクリスタル・パレス・ロックを容易に選んだ。Oracle Cloud Infrastructure(OCI)自動化エンジンのブループリントは、GitHubで入手できます。.

Orion Infrastructureのセキュリティ

リバース・ポート転送サービス(HTTPS/SSH/IPsec)用のFIPS 140-3準拠のMFAトリプル暗号化。ベルト、サスペンダー、撹拌!

RBAC モデル、ペッパー付きオルスルス OTP/TOTPの課題

すべてのインフラストラクチャ・アカウントのログイン・アクセスには、OCIアカウントを含むマルチファクタ認証資格証明を指定する必要があります。設計上、この方針の裏側はありません。

すべての従業員の企業マシンへのsshアクセスには、YubiKey PKIと、YubikeyのPKCS11スロットに格納されているECDSA-SHA-2-NISTP-256認可秘密キー、またはED25519-sk Pkeysとの直接スマート・カード統合が必要です。

固定パスワードはディスクに格納されません。sudo / RBAC使用のヘッドレス自動化は、この制限正当な理由から。しかし、ツール さまざまな種類のプロンプトに応答するトイルを排除する。

ビルドおよびCGIスクリプトのサンドボックス実行

デプロイ”共有なし” ゾーンビルド。デフォルトではネットワーク可用性はゼロになります。これは、お客様が構築してアクセスまたは変更できるものは、お客様自身のアセットのみであり、他のお客様やゾーン自体のその他のシステム・パスではありません(さらに、/tmp。さらに、ビルド中にインターネットにアクセスできるのは、ビジネスおよびエンタープライズのお客様のみです。これは、ビルド要件に合わせてカスタマイズできる独自のunique Solarisゾーンを使用しているためです。

CGIスクリプトの場合はDitto。CGIスクリプト以外のものへの書込みアクセスに関して完全にロックされます。/tmp.

エンドツーエンド暗号化

• OpenSSL v4+ HTTPS FIPS 140-3接続用のTLS 1.3 (+FS) AES(256) SHA(256)

• OpenSSH v10+ ED25519 FIPS 140-3、Post-Quantum KexAlgorithm/NIST準拠キー(クロスホスト用) lo リバースポート転送

• IPsec/IKEv2/PFS AES(256)クロスリージョンVPN用FIPS 140-2

• ZFS暗号化用のAES(256)

Zero Trustについて

基本的な前提ゼロトラスト・アーキテクチャ は、クラムの生理学の周りにあなたのネットワークセキュリティを設計することを避けることです: 外側では困難ですが、あなたが入ったら柔らかく、緩い。そのため、さまざまなPoint of Presence (POP) LAN内の意味のある特権ネットワーク・ポートはすべて、ベアメタル・マシンのループバック・デバイス・インタフェースにのみ公開されます。lo0は、(逆の)ポート転送されたSSH接続to itのコンテキストでのみ意味があります。

HTTPプロキシではなくTCPプロキシを使用し、MSAバックエンドも使用しません。したがって、暗号化されていないTLS Webトラフィックを認識するホストは、それを復号化するホストのみです。同じルールがSubversionトラフィックに適用されます— サービス・エンドポイントへの直接のエンドツーエンドTLS暗号化トラフィックのみが、暗号化されていないデータをワイヤ上に表示します。

MSAレイヤーおよびプライベート・データ・エクスポージャのレイヤーと他のベンダーとの幸運。敵の”非機能工学” 複雑さです。製品が大規模なMSA鉱山フィールドではなくフェデレーテッドモノリスの場合、有意義なセキュリティ約束を提供する方がはるかに簡単です。これは、Orionと競合他社の分野との別の矛盾する差別化要因です。

このインフラは、地域がオンラインになると完全に自動化されますが、アーキテクチャについて公に共有できるのはそれだけです(ホブスの透明性を軍事マントラとバランスさせる)。”緩い唇の流しの船” 科学よりも芸術である)。安心— BREAKINGTHEANTISPOOFING lo0 Solaris 11 (BSD)パケットフィルタ自体内の保護は、顧客アカウントであっても、これらのサービスにアクセスするための意味のある手段はありません。

マスターOCI制御アカウントが侵害されても、すべての顧客資産の機密性と整合性は違反したままです。ブラックハットができることは、お客様のWebサイト可用性を混乱させることです。特に、Subversionサービス・データ・レコードにアクセスできません。悪いAppleのOCIアクセスが終了すると、OCIインフラストラクチャ全体を48~72時間でゼロから再構築できます。

ロギング、監視および監査

企業のお客様はSplunkアカウントを作成することをお勧めします。また、必要なすべてのグローバルPOPからお客様のアカウントにほぼリアルタイムのWebログを提供します。サーバー側のCGIスクリプトのエラー・ログは、Splunkでも使用できます。

オラクルは、世界中のすべてのOCI POPからサービスの可用性を監視し、サーバーの停止が30秒を超えた場合にHA (可用性ドメイン)またはリージョナル・フェイルオーバー・イベントをトリガーします。

ACL監査は、Apacheライセンスを使用してWebサイトのSubversion HEADを構築するだけで実行できます。Orion SSG スクリプトおよび結果のビルドをwww/.acl いつでもあなたのチェックアウトディレクトリにファイル。通常、最新のハードウェアでは、ビルド・プロセスに10秒から15秒かかりません。

Subversionサーバー側のコミット・フックも、監視上の懸念に応じてカスタマイズできます。単純なコミット・メーラーからsvnpubsubデーモンへのセキュアなアクセスまで、使用可能なカスタム構成はいくつもあります。

Orionアプリケーションのセキュリティ

Public SSRは臭い

Knee-jerkのダイナミズムとクラウドフォローは、オンラインシステムを構築および運用する人々にとって壊滅的なリスクと不合理なコストをもたらしました。Orionは、より考慮されたアプローチを取っており、静的システムと動的システムの間の応答性の従来の区別を曖昧にする静的コンテンツ・テクノロジを開発しています。ジョーはこのアプローチで何かをしていると思うし、彼がどこにそれを取ることができるか見たい。
– Paul Vixie、インターネットパイオニア

懸念とエンジニアリングのトレードオフの分離

簡単に言えば、他のすべてのwikiプラットフォームの仕組みは、SQLベースの動的CMSです。ログイン コンテンツをすばやく簡単に変更できるようにするアプリ。そのために、誰かがオンラインでそのコンテンツを表示する必要があるたびに、リアルタイム(またはWebページ・キャッシュ)で結果を再構築する必要があります。

(noSQL) Orionでは、編集とレンダリングを、2つの独立したソフトウェア・スタックで処理する必要がある2つの個別の問題として受け取ります。編集インタフェースには、より多くのプロセス、設計、検証および依存性管理が投資されます。これは、レンダリング・スタック上のソフトウェアを、bog-standard Web認証およびアクセス制御が関係するベアボーンSSI対応のApacheファイル・サーバーに制限できるようにするためであり、コンテンツが編集されるよりも頻繁に表示されることを楽観的に期待しています。

その結果、編集エクスペリエンスは、ログインが無効な独立したWebスタックでアクセスできない場合に発生し、変更がアップロードされると少し速くなり、汚れが少なくなります。変更したコンテンツを検証して構築するため、依存ページのコーパス全体(編集時、レンダリング時ではなく)とともに検証して構築します。ビルドは、別々に強化されたサンドボックス化されたSolarisゾーンで行われます。ビルド・ログは編集セッションにリアルタイムで公開され、事後およびビジネスの説明責任のためにバージョン管理に保存されます。

実際、コストは、ライブ本番Webサイトでコミットされた公開済の変更を確認する前に、ビルドの技術機械および静的ファイル・デプロイメント・プロセスにさらされる数秒です。

利益は? レンダリングWebサーバーのソフトウェア・スタックのゼロデイまたはパッチが適用されていない脆弱性によって、ライブWebサイトが再びハッキングされることはありません。さらに、編集サイトは匿名のハッキング作業に脆弱**であるため、このドキュメントの残りの部分で実装されている追加の保護に関係なく、地球上の他のWikiベンダーよりもはるかに優れたセキュリティアーキテクチャの立場にあります。

ニートトリックですね。

しかし、それは編集者の経験に実行可能なトレードオフに批判的にかかっています。特許権の適用なしスマート・コンテンツ依存性管理™ 多くの企業にとってはコストがかからないかもしれません。

ACL管理

Orionのセキュリティモデルは、以下の設定により一元管理されます。@path::acl に構成されるlib/path.pm。オフシュート・サーバー構成ファイルは、構築される変更ごとに動的に生成されます。

POSIXファイルシステムのセキュリティモデルを理解すれば、Orionのmod_dav_svn 認可モデルとApache HTTPd Webサーバーの.htaccessコントロール。Webサイトから自動的に生成されます。lib/acl.yml YAML構成。

OpenIDC SSOセキュリティ

すべてのOpenIDセッションCookieは、HttpOnlyおよびSecureフラグが設定されているため、Javascriptセッション盗難の試行は、Orionオンライン・エディタによって効果的に中和されます。

すべてのCookie資格証明ストレージは、HMAC SHA-1ハッシュの下にさらにAES-256で暗号化されます。

SubversionパスワードのBcrypt

調整可能なラウンド数(現在のデフォルトは5) こちらブログエントリ それが関連性を説明している。

汚染されたデータの保護

すべてのPerlランタイムには、-Tフラグで必須のTaintチェックが有効になっています。リモートシェルエクスプロイト.

Wikiの問題

Wiki security involves several factors:

1. UI/APIセキュリティ

2. ミドルウェア/バックエンドのセキュリティ

3. テンプレート横断保護

4. テンプレート文字列リテラル・セキュリティ

5. 検索エンジンACLの互換性

これらの問題は、以下のOrionに関連するため、詳しく説明します。

オンライン・エディタ

オンライン・エディタでは、ユーザー・エージェントのAcceptヘッダーを優先するように設定するだけで、JSON UIがサポートされます。application/json MIMEタイプであるため、セキュリティ制御はUIとAPIの両方で同じです。

Subversionの直接アクセス以外に、管理UI/APIはありません。かわりに、ホストされたWebサイト内でアクセス制御されたダッシュボードを構築するために使用できる、無料検索エンジンで特定のデータビューを提供します。

それ以外の場合、各Webサイトは、Webサイトのベースの構成ファイルによって管理されますlib/ Subversionのソース・マテリアルのディレクトリ。

Subversion ACLは、サーバー側の作業用コピーの読取りアクセスを制御します。

UIを介して使用可能な各作業コピー・リソースは、ユーザーに提示する前に、Subversion ACLに対してクロスチェックされます。このようにして、バージョン管理中のアセット(別名everything)に対して、認可されていないリソースへの読取りアクセスが防止されるようにします。

コミット・アクセスは、Subversion ACLで直接制御されます。

対応する認可されたSubversionコミットがないと、ネットワークを介して構築および表示することはできません。ここでの主な問題は、Wikiページ作成者がコミットおよび構築した編集で利用可能な情報を制御することです。

マークダウン・ソース・ページでテンプレートの前処理を許可する場合は、編集したページのソースに対する変数として、ツリー内の他のファイルの内容をテンプレート引数でどのように使用可能にするかを認識する必要があります。

しばしば、そのように構成されている場合、編集されたページは、ページのヘッダーに独自の依存関係ファイルを宣言できます。これは、Wikiの情報アーキテクチャのセキュリティ制御に対して機能セットの重み付けを行う場合にも考慮する必要があります。あなたのスタンスに関係なく、私たちはデフォルトであなたのサイトを保護します— コンテンツの依存関係およびssi 含む。

オラクルは、お客様のニーズに合わせてガイダンスとサポートを提供することができますが、Orionが支援するWikiで組織の管理資産のスケールを均衡させる方法を決定するのは、お客様次第です。

次の項を参照してください依存性/ACLインジェクション制御 詳細、および簡単なACLを一元的に構成する方法のこのライブ例をチェックアウトlib/acl.yml:

- path: content
  rules:
    "@staff": rw
    "@svnadmin": rw
    "*": r

- path: content/orion
  rules:
    "@staff": rw
    "@svnadmin": rw
    "*": r

- path: lib
  rules:
    "@svnadmin": rw
    "@devops": rw

- path: lib/acl.yaml
  rules:
    "@svnadmin": rw
    "@security": rw

- path: templates
  rules:
    "@svnadmin": rw
    "@frontend": rw

- path: cgi-bin/search.pl
  rules:
    "@svnadmin": rw
    "*":

コンテンツ作成者はページのページ制限を構成できますヘッダー:

Title: Orion Security
Dependencies: *.md.en api/index.md.en
ACL: @staff=rw, *=r
Keywords: security,infosec,appsec,ipsec,devsecops,it,acl,svnauthz,zerotrust

副次的なノートとして、ブランチの作成や変更に追加のACLコントロールを配置しなくても、権限のない担当者が保護されたリソースをブランチにコピーすることはできません。言い換えると、システムは、各支店の自然なライフサイクルを通じて保護資産を維持するために、追加の制御なしで支店の実験をサポートします。

システムACLを構築しますか。

ビルド・システムは完全に認識され、すべて知っていますが、構築された保護されたアセットが、Subversion ACLで管理および管理するチームにのみ表示されるようにすることができます。

ビルド・システムでは、コミット時にブラウザIDEを介してビルドされたファイル名のリストが表示されますが、そのリストは、コミット内のコンテンツ・アクションの追加、更新または削除に依存するリソースへのユーザーの読取りアクセスのみに基づきます。

テンプレート横断制御

参照sanitize_relative_path:

sub sanitize_relative_path {
  for (@_ ? @_ : $_) {
    s#^[\\/]+##g;
    s/^\w+://g; #Windows GRR
    s#([\\/])+#$1#g;
    s#/\./#/#g;
    1 while s#[\\/][^\\/]+[\\/]\.\.[\\/]#/#;
    s#^(?:\.\.?[\\/])+##;
  }
}

このコードにより、この項の次のルールが適用されます。

includeおよびextendsタグ

すべてのターゲット・ファイルは、/templates/ フォルダ。そのフォルダをルートとする絶対パスとして参照する必要があります。

ssiタグ

すべてのターゲット・ファイルは、/content/ フォルダ。そのフォルダをルートとする絶対パスとして参照する必要があります。

ターゲット・パスが構成されていない場合@path::patterns 対象のターゲット・パスをアーカイブまたは分類できる一致設定、またはソース・ファイルの最終変更作成者が単にターゲット・パスを表示する権限がないssi 操作が失敗します。

これは、ssi サポートは、サイトのターゲットpermalinksを保持するために、これらの機能セットに対する前提条件です。

文字列リテラルとして渡される正規表現を含むフィルタ・セキュリティ

Dotiac::DTL 内部では、すべての文字列リテラルをURLエンコードしてから公開します。eval セキュリティ上の理由から。次に、フィルタ引数として渡されるとエンコードされたままになります。これは、PCRE文字列リテラルを操作するときにイライラします。

この状況では、私たちのフォークDotiac::DTL urldは文字列をコード化し、正常性チェックを行います。Safe::reval サンドボックスを公開する前にperlregex engineとは逆に言えば、サポートされているフィルタ引数に入力した文字列リテラルは、perl — バックスラッシュを二重にエスケープする必要はありません。

依存性/ACLインジェクション制御

管理者lib/path.pm インポート

ライブラリ/{パス、表示}.pm Subversion ACL

これらのリソースへの書込みアクセスを制御するには、コードベースで有能なユーザーに制限し、バージョン管理下にあるアセット・セット全体(everything)のセキュリティ制御を実装することを承認します。

また、次のものを含めることをお薦めします。@svnadmin 読取り/書込みアクセス権を持つグループですが、Subversion ACLを手動でリセットする必要がある場合でも、厳密には必要ありません。

動的に生成されたルール@パス::acl

ビルド・システムは、lib/path.pm seed_file_deps()とseed_file_acl()のいずれか(または両方)をインポートし、増分ビルドを引き起こすSubversionコミット変更の内部処理でその選択を繰り越します。

制御されたコンテンツ移行トラッキング

完全なバージョン管理履歴をユーザーに公開する場合は、制御された資料の元の場所での承認制御を保持するように注意する必要があります。

それ以外の場合、資料は不注意にも必要な承認なしに履歴研究者に公開される可能性があります。

Orion CMSの移動/削除追跡ロジックは、これをシームレスに処理します。

lib/path.pmでのseed_file_deps()およびseed_file_acl()の使用に関するカスタム・コントロール

これらのシンボルのインポートを超えてlib/path.pmまた、walk_content_tree ()コード・ブロックの実行中に、どのように、どのファイルに適用するかも選択できます。結局のところ、それは単に構成ファイルではなく、コードベースであり、すべてのTuringの完全な機能がありますPerl 私たちは知り、感謝するために来ました!

ビルドされたWebサイトの.htaccessファイル、およびSubversion承認ファイルは、@path::acl 即時コミット時

エフェメラル・ブランチ・ビルドの自動ACL保護。追加構成は不要です。

PCRE検索エンジン内蔵コントロール

Same situation as the general-purpose UI: これは、UIからSubversionサーバーに対してクロスチェックします。

ライブ・サイトでは、マークダウン(ソース・ツリー)検索を有効にすると、検索エンジンはまったく同じことを行います。それ以外の場合は、ライブ・サイトにhttpdサブリクエストを実行して、ユーザーがそのライブ・ファイルにアクセスする権限があるかどうかをテストします(使用するユーザー・データがあるように、検索エンジンにパスワードで保護されている場合)。

コンテンツセキュリティポリシー

• 分析の制限

Google、X、および/またはLinkedIn。

• データ制限

データはサーバーから配信する必要があります。

• コンテンツの制限

コンテンツはサーバーから配信する必要があります。

• コード制限

Javascriptコードは、当社のサーバーから提供する必要があります。

• スタイルの制限

CSSはサーバーからの提供が必要です。

• プラグインの制限

現在はPDFのみ。

クロスオリジン・リソース共有

• アカウントを持つすべてのユーザーは、ログイン資格証明を使用して、他の場所からUI/APIを使用できます。

• 企業および企業のお客様は、OrionをヘッドレスCMS 独自のUIを構築する場合JSON Subversion磁器 またはJSON検索 API。

サードパーティ依存関係

非常に簡潔で時間テスト済の依存関係。主なコンポーネントについては、Orionテクノロジー ページ。

要求時に利用可能なフル・ソフトウェア部品表(SBOM)

お問い合わせ 詳細はこちら