Orion 安全

“穿透隱密的安全性根本不太安全。”

美國 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 與 ECDSA-SHA-2-NISTP-256 授權私密金鑰 (儲存在 Yubikey 的 PKCS11 插槽中) 整合，或與 ED25519-sk Pkeys 直接整合智慧卡。

磁碟上沒有儲存固定的密碼。此 限制 sudo/RBAC 使用無頭自動化，理由良好。然而，我們有工具 以消除回應各種提示的無限可能。

組建和 CGI 命令檔的封閉測試環境執行

我們部署”無共享” 區域建置時，預設為零網路可用性。這表示客戶建置可以存取或修改的唯一項目是自己的資產，而非任何其他客戶或區域本身的任何其他系統路徑 (除了/tmp。此外，唯有企業和企業客戶能夠在建置期間存取網際網路，因為他們正在使用自己的 unique Solaris 區域，而這些區域可以完全根據其建置需求量身打造。

CGI 文稿的 Ditto，在寫入存取時被完全鎖定 。/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) FIPS 140-2 適用於跨區域 VPN

• AES (256) 加密 ZFS

零信任層面

基本處所零信任架構 是為了避免在垃圾的生理上設計您的網絡安全：在外面硬化，但一旦你進入，軟和鬆散。因此，我們不會這麼做；在各種出席點 (POP) 區域網路內，每個有意義的授權網路連接埠都只公開在裸機機器的回送裝置介面上。lo0，且僅在 (反向) 連接埠轉送 SSH 連線至其 *的相關資訊環境中有意義。

我們使用 TCP 代理主機，而非 HTTP 代理主機，也沒有 MSA 後端 ** 因此，唯一可以看到未加密之 TLS Web 流量的主機 **。Subversion 流量適用相同規則— 只會將端對端 TLS 加密流量直接導向 **服務端點 **，即可在纜線上看到未加密的資料。

**MSA 層和多層私人資料曝光 等其他廠商都很幸運。敵人的”非功能工程” 複雜性。當您的產品是 聯合貨幣，而不是大規模的 MSA 礦場 **時，提供有意義的安全承諾會變得更加簡單，這是 Orion 與其競爭對手領域之間的另一個差異化因素。

一旦一個區域在網路上被帶入，這項資訊就會完全自動化，但我們都可以公開分享有關該架構的資訊 (平衡霍布斯與軍人手的透明度)。”鬆嘴唇沉船” 比科學更藝術。放心— 超越防偽lo0 在 Solaris 11 (BSD) 封包篩選器本身當中保護，即使是客戶帳戶，也無法透過有意義的方式存取這些服務。

即使主要 OCI 控制帳戶受到危害，所有客戶資產的** 機密性 和 完整性 仍保持違規。所有的黑帽子都可與客戶網站 可用性 **一起訊息。特別是，他們無法存取 Subversion 服務資料記錄。蘋果的 OCI 存取終止後，我們可以在 48-72 小時內從頭重新建構整個 OCI 基礎架構。

記錄、監督以及稽核

我們鼓勵企業客戶建立 Splunk 帳戶，我們將從您所需的每個全球 POP 將近乎即時的 Web 日誌傳遞給您的帳戶。Splunk 也提供伺服器端 CGI 命令檔的錯誤日誌。

我們會監控全球所有 OCI POP 的服務可用性，如果伺服器停機持續超過 30 秒，則會觸發 HA (可用性網域) 或區域容錯移轉事件。

只需使用 Apache 授權的建置網站的 Subversion HEAD，即可執行 ACL 稽核Orion SSG 指令碼並檢查產生的組建www/.acl 您可以隨時在結帳目錄中的檔案。一般而言，現代硬體上的建置程序將花費不到 10-15 秒的時間。

Subversion 伺服器端確認鉤點也可根據您的監督問題自訂。從簡單的確認郵件程式到安全存取我們的 svnpubsub 常駐程式，都有許多可用的自訂配置。

Orion 應用程式安全

公用 SSR 是氣味

Knee-jerk 的活力和群眾跟蹤導致了災難性的風險和不合理的成本。Orion 採用更廣泛的方法，正在開發靜態內容技術，使靜態與動態系統之間的回應速度與傳統上的區別變得模糊。我認為喬是用這種方法去做些事，我很想看到他可以去的地方。
– Paul Vixie, Internet Pioneer

關心與工程的分離權衡

簡而言之，其他 Wiki 平台的運作方式就是「動態 CMS」，由 SQL 支援克魯德 此應用程式可讓您快速輕鬆地修改內容，每當有人需要在線上檢視該內容時，就必須即時 (或從網頁快取中) 重新建構結果。

在 (noSQL) Orion 中，我們會將編輯和轉譯視為兩個獨立軟體堆疊應處理的個別問題；其中更多的程序、設計、驗證和相依性管理都投資於編輯介面。這樣一來，我們就可以將彩現堆疊上的軟體限制為支援 SSI 的裸機 Apache 檔案伺服器，其中包含標準的 Web 認證和存取控制，而且我們以最佳方式預期檢視內容的頻率比編輯的還要高。

因此，編輯體驗會發生在不可能存取且沒有有效登入的獨立 Web 堆疊上，一旦上傳變更，速度會稍微減少，而且不髒；因為我們驗證並建立修改的內容，以及相依頁面的整個語彙，* 在編輯時間，而不是在轉換時間 *。此組建會在獨立強化、封閉測試環境的 Solaris Zone 中進行。組建日誌會即時發布至編輯階段作業，並儲存在版本控制中，以實現海報和業務問責性。

事實上，成本比建築技術機器和靜態檔案部署流程多出幾秒鐘，才能在現場生產網站上檢視已確認、已發布的變更。

還有什麼好處？您 **在呈現 Web 伺服器的軟體堆疊中，永遠不會看到您的即時網站再次遭到駭客入侵 **，或從未修正的漏洞。此外，編輯網站 **無助於匿名駭客入侵 **，因此無論本文件其餘部分所實施的額外保護為何，您與我們的安全性架構位置比地球上的任何其他 Wiki 供應商更好。

吃棒，不是嗎？

但對於編輯體驗至關重要，該 交易 可行。不申請我們的專利申請智慧內容相依性管理™ 架構，可能不值得許多企業的成本。

ACL 管理

Orion 的安全模型由包含的設定集中管理@path::acl 施作於lib/path.pm。Offshoot 伺服器配置檔案會在每個建立的變更上動態產生。

如果您瞭解 POSIX 檔案系統安全性模型，您就可以前往 Orion 的家。mod_dav_svn 授權模型和 Apache HTTPd Web 伺服器的 .htaccess 控制項，會從您網站的自動產生lib/acl.yml YAML 組態。

OpenIDC SSO 安全性

所有 OpenID 階段作業 Cookie 均為 HttpOnly 且已加上安全旗標，因此 Orion Online Editor 會有效中立 Javascript 階段作業竊取嘗試。

所有 Cookie 證明資料儲存體在 HMAC SHA-1 雜湊底下均會另外加密 AES-256。

Subversion 密碼的加密

可調整的捨入次數 (目前預設值為 5)。以下是部落格項目 這說明了相關性。

隱匿的資料保護

我們所有的 Perl 程式實際執行都啟用了 -T 旗標的強制性 taint 檢查；這是一項功能強大且唯一的 Perl 防護措施遠端 Shell 爆炸.

Wiki 問題

Wiki security involves several factors:

1. UI/API 安全

2. 中介軟體 / 後端安全

3. 範本遍訪保護

4. 範本字串文字安全性

5. 搜尋引擎 ACL 相容性

我們探討這些與以下 Orion 有關的問題。

線上編輯器

線上編輯器支援 JSON UI，只要將使用者代理程式的 Accept 標頭設為偏好即可application/json MIME 類型，因此 UI 和 API 的安全控制相同。

直接 Subversion 存取之外沒有管理 UI/API。相反地，我們會在免費搜尋引擎中提供特定資料 **檢視 **，這些資料可用來建構代管網站內的存取控制儀表板。

否則，每個網站都由網站基礎中的組態檔管理。lib/ Subversion 中來源材料的目錄。

Subversion ACL 管理伺服器端工作複本讀取存取權

透過 UI 可用的每個工作複本資源會對照您的 Subversion ACL 進行交叉檢查，然後再將它們呈現給使用者。如此一來，我們就無法對受版本控制 (又稱為 **所有項目 **) 的資產進行未授權資源的讀取存取。

確認存取權是由 Subversion ACL 直接控制

沒有對應的授權 Subversion 確認，就無法再透過網路建立及後續檢視任何內容。此處的主要問題是控制 Wiki 頁面作者所確認和建立之編輯可用的資訊。

如果您在 Markdown 來源頁面中允許「樣板」預先處理，則必須瞭解樣板引數如何讓樹狀結構中其他檔案的內容作為編輯頁面來源的變數。

通常，如果設定為這麼做，編輯的頁面可以在頁面的標頭中宣告自己的相依性檔案，這也是您在 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#^(?:\.\.?[\\/])+##;
  }
}

此程式碼會強制執行以下段落中的規則。

包含和延伸標籤

所有目標檔案都位於子資料夾中/templates/ 資料夾，且必須作為根目錄位於該資料夾的絕對路徑。

ssi 標籤

所有目標檔案都位於子資料夾中/content/ 資料夾，且必須作為根目錄位於該資料夾的絕對路徑。

若未在其中設定目標路徑@path::patterns 具有可允許將有問題之目標路徑存檔或分類的比對設定，或來源檔案的最後變更作者未獲授權檢視目標路徑，ssi 作業將會失敗。

這是因為ssi 支援是這些功能集的先決條件，以保留您網站的目標 permalinks。

涉及以字串常值形式傳送之正規表示式的篩選安全性

Dotiac::DTL 對所有字串文字進行內部 URL 編碼後，再將其公開eval 基於安全理由。然後，當以篩選引數傳送時，它會保留編碼，這在使用 PCRE 字串文字時會令人失望。

在這種情況下，我們的叉子Dotiac::DTL urldecodes 對字串進行完整性檢查Safe::reval 先將封閉測試環境公開給perl的 regex 引擎。上方是，您在支援的篩選引數中鍵入的字串文字將會公開動詞perl — 您不需要重複跳脫您的反斜線！

相依性 /ACL 射出控制

控制者lib/path.pm 匯入。

程式庫 /{路徑，檢視}.pm Subversion ACL

我們明智地控制對這些資源的寫入存取權，方法是將它們限制在程式碼庫中的人員，並授權在版本控制 (亦即 *所有項目 *) 下對整組資產實施安全控制。

它也是包含的一個好主意@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 () 程式碼區塊時，您也可以選擇要套用這些檔案的方式和目標檔案。畢竟，它不只是一個配置檔案，而是一個代碼庫，具備所有杜林的完整功能Perl 我們想知道，感謝您！

建立的網站 .htaccess 檔案和 Subversion 授權檔案會與@path::acl 確認時立即

臨時分支組建的自動 ACL 保護。需要零其他組態。

PCRE 搜尋引擎內建控制

Same situation as the general-purpose UI: 它會對照 UI 中的 Subversion 伺服器進行交叉檢查。

在即時網站上，搜尋引擎會在您啟用減價 (來源樹狀結構) 搜尋時執行完全相同。否則，它會對您的即時網站執行 httpd 子要求，以測試使用者是否獲授權存取該即時檔案 (假設您有受密碼保護的搜尋引擎，讓使用者資料能夠使用)。

內容安全性政策

• [X 軸] 分析限制

Google、X 和 (或) LinkedIn。

• [X 軸] 資料限制

資料必須由我們的伺服器提供。

• [X 軸] 內容限制

內容必須由我們的伺服器提供。

• [X 軸] 程式碼限制

Javascript Code 必須由我們的伺服器提供。

• [X 軸] 樣式限制

CSS 必須由我們的伺服器提供。

• [X 軸] 外掛程式限制

僅限目前 PDF。

跨來源資源共用

• [X 軸] 擁有帳戶的所有使用者都可以使用其登入證明資料，從其他地方使用 UI/API。

• [X 軸] 企業和企業客戶可以將 Orion 視為一種無頭 CMS 如果他們想要從下列位置建立自己的 UI：JSON Subversion 陶瓷 或JSON 搜尋 API。

第三方相依性

極為簡短且經過時間測試的相依性；其主要元件涵蓋在奧里昂科技 頁面。

完整軟體用料表 (SBOM) 可依要求提供

聯絡我們 以取得詳細資訊。