安全可能不是一個橫切關注？

我正在處理一個非常詳細的安全需求的項目。如果提出的模型與任何情報/安全機構一樣複雜，我會誠實地不會感到驚訝。現在我已經讀到，將安全與業務邏輯結合起來是一個混合問題，因此需要避免。安全可能不是一個橫切關注？

但是，所有抽象安全的嘗試都失敗了，或者像以前一樣產生了像抽象一樣的「抽象」。是否有可能讓安全性如此具體以至於成爲業務規則的一部分？在某些違反安全的情況下，只會屏蔽數據，而在其他情況下會終止會話，而在其他情況下，則會觸發默認值以替代使用。對安全性要求有很多要求。

我的根本問題是：我是否可以處於特殊情況下（即將安全性合理化）或者我不理解關於抽象安全性的基本知識？

編輯：

TL;博士（答案，因爲我理解他們）：認證（你是誰）是一個很有橫切關注點，應該抽象，而授權（什麼都可以你這樣做）是商業邏輯。缺乏這種詞彙並且只有「安全」這個詞（或者可能沒有意識到兩者之間的區別）導致我的困惑。

來源

2011-05-09 ArtB

我認爲您會在[ITSecurity]（http://security.stackexchange.com） /） – AviD 2011-05-09 16:18:25

我認爲當你說「安全性」時，你並不是指*只是*來進行身份驗證和授權，因爲這兩個海報至今都宣稱它是全部存在的...... – AviD 2011-05-09 16:20:00

Avid，我認爲我們是沒有解決其他安全問題，因爲這個帖子特別質疑安全性是否可以成爲業務規則的一部分，而Sql注入攻擊雖然是「安全性」的一部分，但通過編碼模式和實踐來解決，因爲數據跨越各層，而不是在要求中常見的東西 – Andy 2011-05-09 16:23:03

安全性分爲兩部分;認證和授權。認證是一個非常具體的用例。你如何確定一個用戶信任的一組不信任的用戶。我認爲這是交叉性的;您需要將未經身份驗證的用戶保留在您的系統或系統的子集之外。

授權（用戶可以做些什麼）是非常多的商業規則。它可以（而且經常）對每個用例都非常具體和不同。誰決定什麼角色可以做什麼？那麼，業務呢。沒有人能爲你回答這個問題。

在Csla.Net 4框架中，這正是授權的處理方式;作爲一項專門的商業規則。你甚至不限於「用戶在角色中」或「用戶有權限」。「您可以制定更復雜的規則」，如果工作流程步驟未經過此特定步驟，用戶可以編輯此字段。「

來源

2011-05-09 16:18:10 Andy

「安全性分爲兩部分：身份驗證和授權，身份驗證是一個非常具體的用例：我認爲這是交叉性的，授權（用戶可以做些什麼）非常符合業務規則。這激起了我啓蒙的一刻，謝謝。 – ArtB 2011-05-09 16:24:14

很高興聽到它ArtB。 – Andy 2011-05-09 16:56:13

'「安全分爲兩部分：認證和授權」 - 安全性遠不止於此。 – AviD 2011-05-09 18:36:37

我想，如果您的業務邏輯是某種安全服務，那麼會出現例外情況。但是我認爲你的問題可能是你將用戶授權與驗證混淆了。

當然，身份驗證應該有一組與其相關的規則，但最終的結果應該是用戶的標識和會話的創建。

授權將與我們確定用戶角色以及該角色佈置的權限分開。

一個典型的例子是認證返回一個用戶對象並將其存儲在會話中。用戶具有1到多個角色。角色可能具有1到多個特權。業務邏輯方法可能是sendEmail。此方法查詢User對象的特定權限，如果它存在則執行某些操作，如果不執行其他操作。

編輯：安全在我看來應該始終是一個橫切關注，當涉及到用戶，但是如果您的業務邏輯涉及對象的屬性不是用戶，這些對象的CRUD或管理其他用戶，然後它符合您的業務需求，因此是業務邏輯。

來源

2011-05-09 16:15:46

是的，QuarterBack是一個角色。 QuarterBack具有多種關聯的權限。 RunningBack也可能是一個角色，但RunningBack可能具有相同的權限。他們都可能有特權，「跑足球」。您應該能夠查詢User對象以查看是否在其任何角色中都有特定的權限。 – 2011-05-09 16:21:53

「我以爲人們都在倡導在商業代碼中沒有安全的痕跡」。這個陳述過於籠統，我會作爲一般規則提出質疑。您不應該在業務邏輯代碼中正確認證用戶。授權可以由業務邏輯可以共享的全局橫切組件來處理。它不需要比這更復雜。 – 2011-05-09 16:24:54

'「......將用戶授權與認證相混淆」 - 安全性遠不止於此。 – AviD 2011-05-09 18:38:02

安全可能不是一個橫切關注？

回答

相關問題