使用 Systemd 定時器可靠地執行 ownCloud 後台作業
將按需作業運行替換為 systemd 定時器,該定時器每 15 分鐘執行一次 ownCloud 支援的 occ system:cron 命令。
使用 SUSE 支援的 DISA STIG 設定檔(適用於 SLES 15),透過 OpenSCAP 掃描伺服器,並在測試系統上審查基準後才進行修復。例如,假設一位名叫 Alex 的管理員正在為受監管的服務準備一台 SLES 15 伺服器:Alex 使用以下工作流程來識別問題、測試變更並收集證據,但他不會將一次乾淨的自動掃描結果視為合規性批准。
這些命令遵循 SUSE 針對 SLES 15 的最新 STIG 指南。設定檔內容可能會隨著軟體包更新和 DISA 基準測試版本的發布而變化,因此在使用此程序之前,請先驗證適用的版本和系統特定要求。終端影像僅用於示範指令,並不顯示實際掃描輸出。
首先記錄主機的 SLES 服務包、用途、網路角色和應用程式。 Alex 記下哪些服務必須保持可用、管理員如何連接,以及如果安全加固變更導致存取中斷時的復原方法。這個範圍很重要:即使資料庫主機和通用伺服器使用相同的作業系統 STIG 設定文件,它們也可能具有不同的已核准例外。

選擇內容前,請先檢查已安裝的版本:
cat /etc/os-release
hostnamectl
然後透過DISA STIG 官方下載頁面取得適用的 SLES 15 STIG 清單和基準測試修訂版。將清單與系統系列相匹配,並遵循貴組織的評估指南。 SUSE 文件支援「DISA STIG for SUSE Linux Enterprise 15」SCAP 設定文件,但這本身並不能確定貴機構需要哪個版本或對主機進行認證。
在已註冊且可存取對應儲存庫的 SLES 系統上,安裝 OpenSCAP 命令列公用程式和 SCAP 安全指南內容:

sudo zypper install openscap-utils scap-security-guide
以下列出的軟體套件名稱和 SLES 15 資料流位置均記錄在SUSE 的 OpenSCAP 安全加固指南和SUSE 的 STIG 流程中。軟體包儲存庫和設定檔版本可能會因服務包和更新等級而異。請列出已安裝的資料流並檢查候選文件,而不是假設文件名稱或設定檔:

ls -1 /usr/share/xml/scap/ssg/content/ssg-*-ds.xml
oscap info /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml
確認 SLES 15 資料流存在,且設定檔清單中包含該檔案stig。如果缺少該文件或設定文件,請停止並解決軟體包或儲存庫不符的問題;請勿使用其他作業系統的基準測試程式。
在產生報表之前,請建立受保護的證據目錄。先進行掃描,無需更改系統設定:

sudo install -d -m 0700 /root/stig-review
sudo oscap xccdf eval \
--profile stig \
--results /root/stig-review/baseline.xml \
--report /root/stig-review/baseline.html \
/usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml
開啟 HTML 報告並仔細查看每項結果,尤其要注意失敗項目、錯誤以及無法檢查的規則。請妥善保存 XML 和報告,因為它們是敏感的配置資訊。這些資訊可能洩漏主機詳情和安全狀況,因此只能透過授權管道儲存或傳輸。
接下來,在非生產環境中複製或建立伺服器快照。在應用自動化變更之前,請驗證應用程式行為、身分存取、網路、監控和復原功能。 SUSE 提醒管理員,由於修復會更改系統配置,因此請務必先在生產環境之外進行測試。在測試主機上,文件中記錄的即時修復方法如下:

sudo oscap xccdf eval --remediate \
--profile stig \
--results /root/stig-review/remediation.xml \
/usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml
產生的結果可能包含修復前和修復後的測試結果。標記為「已修復」的規則fixed表示已套用自動修復程序且該規則通過了評估;標記error為「未修復」則表示該規則的修復失敗。這兩種狀態均不能取代對底層需求的運行測試或審查。
在審查測試行為後,使用新的輸出路徑執行一次單獨的掃描。僅掃描評估有助於區分當前狀態和修復運行後的狀態:

sudo oscap xccdf eval \
--profile stig \
--results /root/stig-review/final.xml \
--report /root/stig-review/final.html \
/usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml
不要指望每條規則都能自動修復。應根據系統所選的 DISA 清單版本,對規則的完整檢查和修復文字進行調查。某些規則需要服務所有者的明確決策、特定站點的配置或人工證據。如果某條規則不適用或無法滿足,則應透過組織的正式例外處理流程記錄其理由和補償控制措施;更改或調整設定檔本身並不能使該要求得到滿足。
為了方便檢查清單的審核,SUSE 文件中提供了匯出 XCCDF 檔案的方法,該檔案可以匯入 DISA STIG Viewer 中。請使用支援的選項產生該文件,然後根據目前使用者說明將其匯入到 Viewer 中:

sudo oscap xccdf eval \
--profile stig \
--stig-viewer /root/stig-review/results_stig.xml \
/usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml
Alex 為虛構伺服器提供的證據包記錄了主機和服務包標識、基準測試版本、SCAP 內容版本、掃描日期、基線報告和最終報告、修復措施、人工檢查以及已批准的例外情況。請確認這些文件存在,並且只有授權審核人員才能讀取:

sudo ls -l /root/stig-review
在宣布任務完成之前,請先驗證最終報告是否反映了變更後的掃描結果,所有剩餘的發現項是否都有負責人和處理方式,以及伺服器所需的各項服務是否仍正常運作。 STIG 合規性是一種與特定基準和系統範圍相關的評估狀態;OpenSCAP 支援該評估,但不授予認證或保證滿足所有站點要求。
將按需作業運行替換為 systemd 定時器,該定時器每 15 分鐘執行一次 ownCloud 支援的 occ system:cron 命令。
透過 Apache、Nginx 或反向代理程式追蹤 WebDAV 請求,然後使用經過驗證的 PROPFIND 測試確認 ownCloud 同步功能正常。
透過設定其規範 URL 並從伺服器本身檢查 DNS、HTTPS 和反向代理路由,修復 Nextcloud 缺少出站位址警告的問題。
透過本機 Unix 套接字配置 APCu 和 Redis,以實現 Nextcloud 快取和檔案鎖定,並提供目前和舊版 Nextcloud 的步驟。
檢查 Nextcloud 的 cron 模式,修復其 systemd 服務和計時器,並驗證後台作業在啟動後以及每隔五分鐘運行一次。
啟用可靠的 Nextcloud 檔案鎖定,選擇適當的 Redis 或 Valkey 後端,並驗證警告是否清除,同時避免並發檔案變更的風險。
使用最新更新、HTTPS 和 HSTS、精確的反向代理信任以及針對公共伺服器的檢查,修復 Nextcloud 掃描中常見的錯誤。
為需要加密的儲存配置 Nextcloud SSE,保護加密金鑰,並在加密現有文件之前測量傳輸和 CPU 影響。
將 Nextcloud 的檔案搜尋連接到 Elasticsearch,索引文件內容,並選擇適合您的伺服器和安全需求的設定。
配置 Nextcloud 在規定的保留期後刪除已刪除的文件,可靠地安排後台作業,並避免執行清除所有使用者回收站的命令。