2010-07-26 134 views
10

關於安全性的大多數文獻都着手在開始制定機制和實施之前定義安全策略的重要性。雖然這看起來合乎邏輯,但對於確定安全策略的真正含義還不清楚。定義系統的安全策略

在這裏沒有人有在定義安全策略的經驗,如果是這樣:

1)什麼是這樣定義的結果?對於分佈式系統而言,這種策略的形式是否包含一系列關於系統安全要求(允許和不允許)的陳述?

2)政策可以採用機器可讀的形式(如果有意義的話),如果可以的話如何使用?

3)如何維護這樣的政策?政策是否保留爲系統中的文檔(與所有其他文檔一樣)?

4)有必要引用代碼中的策略文檔嗎?

Brian

+0

這似乎不是關於編程。由於顯然是關於企業級安全性,因此投票遷移到Server Fault。 – 2010-09-07 16:00:05

+2

@大衛:我強烈反對。在設計具有安全隱患的系統時,其實施的機制必須支持一系列潛在的政策。 – Novelocrat 2010-09-07 21:42:20

+0

@Novelocrat:當然,編程上述機制完全在這裏討論。然而,這是關於建立一些將以各種方式實施的規則,一些可能涉及編程,這不是關於SO的主題。 – 2010-09-08 14:10:29

回答

-1

如果您必須設計安全策略,爲什麼不考慮用戶和權限?

所以,假設你有一個API的東西。考慮一些用戶的安排,將他們分成他們想做的事情和他們需要做的最低權限。所以如果有人只需要從數據庫中讀取文檔,那麼API本身不會讓用戶做其他事情。

想象一下,這是一個Web JSON API。用戶點擊一個按鈕,JS處理請求併發送它。通常情況下,它可以正常工作,但如果有人篡改請求,服務器只是返回一些錯誤代碼,因爲它只是將用戶可以執行的一些操作列入白名單。

所以我認爲這一切歸結爲用戶和權限。

+0

這非常狹隘地集中在一種安全環境上。其他環境將有非常不同的設置。例如,考慮一個針對統計信息披露的要求。或者允許的操作取決於當前數據和條件的系統。 – Novelocrat 2010-09-07 14:42:10

+0

它被故意簡化爲我認爲是您必須制定政策的最常見情況。恕我直言,大多數安全策略是關於應該或不應該訪問某些數據的最終用戶。除了這個問題很難完全解決(我希望你去嘗試,因爲你可能比我有更好的理解)。 – 2010-09-09 02:13:24

+0

'「或者一個允許的操作取決於當前數據和條件的系統」 - 這似乎是「用戶和白名單權限」方法可以工作的一種方式。 – 2010-09-09 02:15:19

1

開放Web應用安全項目OWASP是一個語言無關的項目,教導安全和提供測試和支持軟件的工具。雖然它是以網絡爲中心的,但許多核心思想都是廣泛適用的。該網站面向軟件工程師和管理人員。

1

當人們談論「安全策略」時,他們可能指的是兩種不同類型的安全策略。

其中之一是高層次的,通常由管理層定義。這個安全策略的主要讀者是人。它是一份文件,用於界定管理層思想中安全的目標,背景,期望和要求。本政策中使用的語言可能含糊不清,但這是適用情況下安全性的基本「法律」。參與的每個人都應遵循這樣的政策

1)該政策的結果是管理層明確定義的安全要求。有了這些政策,相關人員就可以瞭解管理層的期望,並在必要時作出與安全有關的判斷。

2)由於此類安全策略的主要讀者是人類,而且這些陳述通常非常籠統,因此它可能不是機器可讀的形式。但是,可能會根據策略定義一些文檔,即安全準則,過程和手冊。他們按照安全實際應該如何實施的細節水平不斷提高。例如,安全策略中定義的要求可以實現爲針對不同操作系統的強化手冊,以便管理員和工程師可以高效地執行強化任務,而無需花費太多時間來解釋管理層的想法。然後可以將硬化手冊變成一組機器可讀配置(例如,最小密碼長度,在鎖定賬戶之前的最大失敗登錄次數等)使硬化任務自動化。

3)所有參與者都可以訪問該文檔,並由管理層定期審查。

4)實際上可能很難做出這樣的參考。安全策略可能會不時更新,如果策略更改僅影響某些參數,您可能不希望重新編譯程序。但是,在設計sepc等開發文檔中引用策略是很好的。

另一種類型的「安全策略」可能只是將這些參數集引用爲安全程序。我發現一些安全程序真的喜歡用「策略」這個詞來使它們的配置更加有組織和結構。但無論如何,這些「安全策略」實際上只是安全程序遵循的價值觀和/或指令。例如,Windows有自己的一套「安全策略」,供用戶配置審計日誌記錄,用戶權限等。這種「安全策略」(程序參數)實際上是基於第一種類型的「安全策略」 (來自管理層的要求),如上所述。

我可能在這方面寫得太多了。希望能幫助到你。