separation of duties

Security Patterns

Meaning

Separation of duties is a security principle that divides responsibilities among different individuals or system components to prevent any single entity from having complete control over a critical process. It reduces the risk of error or fraud by requiring collusion to misuse authority. In software, it translates to designing distinct modules or services for distinct functions such as authentication, authorization, and auditing.

Primary Function

Security design principle

Communicative Purpose

Ensures that no single component or role can both perform and conceal an erroneous or malicious action.

Pattern

class ServiceA: def execute_duty_a(self, data): # duty A logic return outcome_a class ServiceB: def execute_duty_b(self, data): # duty B logic return outcome_b

Core Structure

class ...: def ...(self, ...): ... return ... class ...: def ...(self, ...): ... return ...

Função primária

Security design principle

Propósito comunicativo

Ensures that no single component or role can both perform and conceal an erroneous or malicious action.

Situações de gatilho

Implementing authentication and authorization systems; designing financial transaction processing; setting up audit logging where logs must be independent of the logged activity.

Contextos

Enterprise applications, cloud services, financial systems, role-based access control frameworks.

Padrão

class ServiceA: def execute_duty_a(self, data): # duty A logic return outcome_a class ServiceB: def execute_duty_b(self, data): # duty B logic return outcome_b

Estrutura central

class ...: def ...(self, ...): ... return ... class ...: def ...(self, ...): ... return ...

Slots de substituição

ServiceA: name of first responsibility class; ServiceB: name of second responsibility class; execute_duty_a/execute_duty_b: method names describing the duty; data: input payload; outcome_a/outcome_b: result of duty.

Colocados típicos

role-based access control
audit logging
least privilege
modular architecture

Substituições comuns

single responsibility principle
defense in depth

Erros comuns

Combining authentication and authorization in the same module; allowing one service to both create and approve a transaction.

Similar / contraste

Single Responsibility Principle (SRP) – focuses on cohesion within a module; Separation of Duties focuses on distributing trust across modules.

Interferências

Coming from languages with prevalent global state (e.g., C globals): may assume one module can directly modify another's state, violating SoD.

Família do chunk

least privilege
defense in depth
audit trail

Nuance

SoD is about trust boundaries, not just code organization; over-segregation can increase complexity and latency; ensure interfaces are well-defined.

Efeito pragmático

Reduces risk of fraud and errors by requiring collusion to misuse authority; improves accountability and simplifies auditing.

Dica de memória

Think of a bank: one teller handles cash, another approves loans.

Nota

Audit logs should be written to an immutable store that the service generating the events cannot modify.

Upgrade path

Implement role-based access control (RBAC) with centralized policy engine.

Frequência: MediumFormulaicidade: FlexibleTipo de construção: Design principlePrioridade de aquisição: Recognition firstPrioridade de output: BothTag de espaçamento: Long-term

Examples

class AuthService: def authenticate(self, username, password): # verify credentials return username == "admin" and password == "secret" class Authorizer: def authorize(self, user, action): # check permissions if user == "admin": return action in ["read", "write"] return action == "read" # usage example auth = AuthService() authz = Authorizer() if auth.authenticate("admin", "secret"): if authz.authorize("admin", "write"): print("Access granted") else: print("Permission denied") else: print("Authentication failed")

class TransactionCreator: def create(self, amount, account): # create a pending transaction record return {"amount": amount, "account": account, "status": "pending"} class TransactionApprover: def approve(self, transaction, approver): # approve only if approver has authority if approver == "manager": transaction["status"] = "approved" return transaction raise PermissionError("Approver lacks authority") # usage example creator = TransactionCreator() approver = TransactionApprover() pending = creator.create(1000, "ACC123") try: approved = approver.approve(pending, "manager") print("Transaction approved:", approved) except PermissionError as e: print(e)

import datetime class BusinessLogic: def process(self, data): # core processing logic result = data * 2 AuditLogger.log("process", data, result) return result class AuditLogger: @staticmethod def log(action, input_data, output_data): timestamp = datetime.datetime.utcnow().isoformat() # write to an immutable audit store (e.g., append‑only file) with open("audit.log", "a", encoding="utf-8") as f: f.write(f"{timestamp} | {action} | in:{input_data} out:{output_data}\n") # usage example logic = BusinessLogic() print(logic.process(42))