2009-10-10 69 views
2

我們的開發團隊有4個環境: Dev,Test,QA和Production,並且在整個環境中按順序改變進度。SOX是否限制訪問QA環境或僅生產?

我們的DBA給了「薩班斯法案」作爲否定團隊領導,開發人員和測試更新只讀訪問數據庫對象的測試,QA和生產環境的原因。因此,我們無法驗證部署是否正確執行。

我可以看到限制對生產數據的訪問。數據可能很敏感。但是,我們擁有對數據的完全讀取權限。但是我希望能夠看到生產中的代碼,以驗證它是應該在生產中的代碼,並且某些東西沒有錯誤地部署或者不在部署中。即使我們的部署過程是自動化的,仍然需要驗證自動化過程是否按預期工作。

該做什麼SOX法規要求真正限制進入非生產環境? SOX真的有什麼話要說開發者是否應該被拒絕READ ONLY只能訪問生產數據庫對象(代碼/模式)還是這個限制真的是自己強加的?

+0

這不是一個程序設計,而是一個法律問題,因此是題外話題。 – Deduplicator 2016-02-20 16:44:20

回答

2

據我所知,在我的經驗,薩班斯法案導致我沒有任何讀取訪問生產數據庫。這可能是因爲像信用卡號碼那樣的東西,因爲在我們的開發環境中,真實的號碼被改變和加密了,所以我們無法看到任何東西。

另外,在正確的部署文檔中,您應該在QA上模擬生產時會發生什麼情況,因此您不應該對QA執行任何操作,因爲如果您必須執行某些操作,則會出現問題與您的部署文檔。您應該修復文檔,以便系統管理員可以在沒有開發人員幫助的情況下進行部署。

在一個公司,他們實際上有不同的網絡,開發商根本無法到達,爲了遵守SOX法規的QA。

本文檔可能幫助你: http://hosteddocs.ittoolbox.com/new9.8.06.pdf

+0

正如預期的那樣,文檔鏈接提到「薩班斯 - 奧克斯利法案(SOX)法規遵從的關鍵要求是管理過程中變更職責的分離。在一個打包的應用程序環境中,職責分離意味着 同一個人不能做出改變到開發數據庫,​​然後移動 ,更改爲生產數據庫「 ..但是沒有提及SOX限制* READ ONLY *訪問開發或生產服務器上的代碼。 我仍然認爲這是自我強加的限制,我的部門爲了讓我們的團隊不那麼有效並且已經運作了而放在自己身上。 – ChadD 2009-10-11 13:01:50

+0

根據我的經驗,我還沒有閱讀prod數據庫的讀取權限,所以可能是顧問建議將此作爲一種安全的方式。 – 2009-10-12 00:12:49

0

我的理解是,爲開發人員提供讀取到QA數據庫唯一途徑是不是違反薩班斯法案。

有可能你需要確保訪問與記錄的正式理由沿授予,並通過變更控制系統適當的審批。

0

我建議看着像Stackify一個工具,可以幫助給生產服務器和數據庫的訪問限制。他們的系統旨在幫助您管理和排除製作應用程序,同時無法更改任何內容。他們提供審計報告等,以協助合規。

相關問題