Sten Eikrem - Information Security & Risk Management

Access Control and Data Protection - Getting the Details Right

13 min read

Access Control and Data Protection: Getting the Details Right

Article 6 of 7 in the System Security Concepts series

Why Details Matter

Access control and data protection appear in every security concept. Yet they’re often documented poorly—generic statements that provide no implementation guidance, miss critical details, and frustrate both architects and auditors.

Generic: “System implements role-based access control” Missing: Which roles exist? What can each role do? How are roles assigned? Who reviews access?

Generic: “Data is encrypted in transit and at rest” Missing: Which encryption algorithms? Where are keys stored? Who can decrypt? What data isn’t encrypted and why?

The problem isn’t that these details don’t exist—architects implementing the system know them. The problem is they’re not documented in the security concept, creating three failures:

Design review failure: Security teams can’t meaningfully review access control design without knowing the authorization model. “We use RBAC” tells them nothing.

Audit failure: Auditors need evidence that access controls work as designed. Generic statements provide no testable criteria.

Change management failure: When architects change, knowledge walks out the door. The next architect must reverse-engineer access control logic from code.

This article addresses how to document access control and data protection with enough detail to enable review, audit, and maintenance without overwhelming the reader with implementation specifics.

Authentication: Who Are You?

Authentication proves user identity. Most systems inherit authentication from enterprise IAM capability (covered in Article 5). What belongs in the security concept is authentication requirements, not authentication implementation.

Authentication Strength Requirements

Different user populations may require different authentication strength:

## Authentication Requirements
 
### Standard Users (Internal Employees)
- Method: SSO via Azure AD
- Factors: Username/password + MFA (Microsoft Authenticator app)
- Session: 30-minute idle timeout, 8-hour absolute timeout
- Re-authentication: Required for sensitive operations (data export, user management)
 
### Administrative Users
- Method: SSO via Azure AD + Privileged Access Management (CyberArk)
- Factors: Username/password + MFA + Just-in-Time elevation
- Session: 15-minute idle timeout, 2-hour absolute timeout
- Re-authentication: Required for every privileged operation
 
### API Clients (Automated Systems)
- Method: OAuth 2.0 Client Credentials flow
- Factors: Client ID + Client Secret (stored in Azure Key Vault)
- Session: Token lifetime 1 hour, no refresh
- Rotation: Client secrets rotated quarterly

This format specifies requirements without implementation details. Architects know what authentication strength to implement. Security reviewers can assess adequacy. Auditors can test implementation against requirements.

Authentication Failure Handling

Document how the system responds to authentication failures:

Account lockout: 5 failed attempts within 15 minutes → account locked for 30 minutes

  • Rationale: Balance brute-force protection with user convenience
  • Unlock: Automatic after 30 minutes, or manual by service desk

Suspicious activity: Impossible travel, unusual location, compromised credential detected → require additional authentication challenge

  • Implementation: Azure AD Identity Protection
  • User Impact: Additional verification required before access granted

Failed MFA: User fails MFA challenge → authentication denied, incident logged

  • No fallback to single-factor authentication
  • Service desk can provide temporary access code (valid 15 minutes, single use)

Federation and Trust Boundaries

If system accepts authentication from external identity providers, document trust model:

## Federated Authentication
 
### Trusted Identity Providers
- Partner Organization A: SAML 2.0 federation with Azure AD B2B
- Partner Organization B: SAML 2.0 federation with Okta
 
### Trust Requirements
- IdP must provide: NameID (email), First Name, Last Name, Organization
- IdP certificate: Must be signed by public CA, minimum 2048-bit RSA
- Metadata: Must be updated when certificate rotates
- Revocation: Partner access revoked within 24 hours of contract termination
 
### Authorization After Authentication
- External users mapped to "Partner" role (read-only access)
- Elevated permissions require internal sponsor approval
- Access reviewed quarterly by business owner

Authorization: What Can You Do?

Authentication proves who you are. Authorization determines what you can do. This is where security concepts frequently lack detail.

Role-Based Access Control (RBAC) Documentation

Don’t just state “system uses RBAC.” Document the authorization model:

## Authorization Model: Role-Based Access Control
 
### Role Definitions
 
| Role | Business Function | Typical Users | Permissions Summary |
|------|------------------|---------------|---------------------|
| Viewer | Read-only access for reporting | Finance analysts, auditors | View all data, export reports |
| Sales User | Daily sales operations | Sales representatives | View assigned customers, create/edit opportunities, view all products |
| Sales Manager | Team management and oversight | Regional sales managers | All Sales User permissions + view team performance, reassign opportunities, approve discounts <10% |
| Sales Director | Strategic oversight | VP Sales, Sales Directors | All Sales Manager permissions + view company-wide pipeline, approve discounts >10%, user management |
| Administrator | System configuration | IT Operations | All permissions + user management, system configuration, audit log access |
 
### Permission Matrix
 
| Function | Viewer | Sales User | Sales Manager | Sales Director | Administrator |
|----------|--------|------------|---------------|----------------|---------------|
| View own customers | ✓ | ✓ | ✓ | ✓ | ✓ |
| View all customers | ✓ | ✗ | ✓ | ✓ | ✓ |
| Create opportunity | ✗ | ✓ | ✓ | ✓ | ✓ |
| Approve discount <10% | ✗ | ✗ | ✓ | ✓ | ✓ |
| Approve discount >10% | ✗ | ✗ | ✗ | ✓ | ✓ |
| Export customer data | ✓ | ✗ | ✓ | ✓ | ✓ |
| User management | ✗ | ✗ | ✗ | ✗ | ✓ |
| System configuration | ✗ | ✗ | ✗ | ✗ | ✓ |
 
### Role Assignment Process
- Request: Manager submits access request via ServiceNow
- Approval: Role assignment approved by user's manager + system owner
- Implementation: Roles mapped to Azure AD groups, synchronized hourly
- Review: Quarterly access review by system owner
 
### Segregation of Duties
- Sales Users cannot approve their own discounts
- Administrators cannot create/approve sales opportunities (read-only access to business data)
- No single user has both "create transaction" and "approve transaction" permissions

This level of detail enables:

  • Design review: Security team can assess whether authorization model prevents common risks
  • Implementation guidance: Developers know exactly what each role can do
  • Audit testing: Auditors can verify role assignment and segregation of duties

Data-Level Access Control

Some systems require finer-grained access control than role-based:

## Data-Level Access Controls
 
### Customer Data Access
- Principle: Users can only access customers they support
- Implementation:
  - Sales Users: Assigned customers only (defined in CRM system)
  - Sales Managers: Own customers + team members' customers
  - Sales Directors: Customers within assigned region
  - Finance/Legal: All customers (business need)
 
### Geographic Data Restrictions
- EU customer data: Accessible only to EU-based users (GDPR compliance)
- US customer data: No restrictions
- Implementation: User location attribute (Azure AD) + data residency flag (customer record) → access decision at query time
 
### Time-Based Access
- Financial data: Read-only except during month-end close window
- Implementation: Role permissions change based on system date
- Override: CFO approval required for off-cycle financial data modification

Privileged Access Management

Document how privileged access is controlled:

## Privileged Access Management
 
### Privileged Operations
- Database administration (direct SQL access)
- System configuration changes
- User permission modifications
- Audit log access
 
### Just-in-Time Access
- Normal state: Administrative accounts have no elevated permissions
- Elevation: Administrator requests elevation via CyberArk
- Approval: Automatic for standard tasks, manager approval for sensitive operations
- Duration: 2-hour maximum elevation period
- Audit: All privileged operations logged with business justification
 
### Emergency Access
- Break-glass account: Single emergency admin account with direct database access
- Storage: Sealed envelope in physical safe (two-person access)
- Usage: Only during CyberArk outage preventing normal administrative access
- Notification: CISO notification within 1 hour of break-glass account usage
- Review: Post-incident review of all actions taken

Data Classification and Handling

Data classification drives protection requirements. Most organizations have classification schemes. Few security concepts document how they’re applied to specific systems.

System Data Inventory

## Data Classification Inventory
 
### Confidential Data (Highest Classification)
- Customer financial data: Revenue, payment terms, credit limits
- Employee compensation: Salary, bonus, equity information
- Strategic information: M&A plans, pricing strategies, product roadmaps
- Volume: ~5% of total data
- Storage: Database encrypted at rest, restricted access
- Transmission: TLS 1.3 only, no email transmission
- Retention: 7 years (regulatory requirement)
 
### Internal Data
- Customer contact information: Names, email, phone
- Sales pipeline: Opportunities, forecasts, win/loss records
- Product information: Specifications, pricing (non-strategic)
- Volume: ~90% of total data
- Storage: Database encrypted at rest, standard access controls
- Transmission: TLS 1.3, email permitted (encrypted)
- Retention: 3 years (business requirement)
 
### Public Data
- Marketing materials: Product descriptions, case studies
- Public pricing: List prices (not negotiated rates)
- Volume: ~5% of total data
- Storage: No encryption required, public access permitted
- Transmission: No restrictions
- Retention: Indefinite

Data Handling Requirements by Classification

## Data Handling Requirements
 
### Confidential Data
- Access: Role-based authorization + business need justification
- Sharing: Internal only, external sharing requires CISO approval
- Export: Audit logged, limited to specific roles
- Display: Masked in logs, partially masked in UI (credit card: ***-***-***-1234)
- Disposal: Secure deletion (overwrite), cryptographic erasure (destroy keys)
 
### Internal Data
- Access: Role-based authorization
- Sharing: Internal + authorized partners (via secure channel)
- Export: Audit logged
- Display: Full visibility for authorized users
- Disposal: Standard deletion
 
### Public Data
- Access: Unrestricted
- Sharing: Unrestricted
- Export: Unrestricted
- Display: Full visibility
- Disposal: Standard deletion

Encryption: Protecting Data

“Data encrypted at rest and in transit” is insufficient. Specify what, how, and why.

Encryption in Transit

## Data Protection in Transit
 
### External Communications (Internet)
- Protocol: TLS 1.3 (TLS 1.2 minimum)
- Cipher Suites: ECDHE-RSA-AES256-GCM-SHA384, ECDHE-RSA-AES128-GCM-SHA256
- Certificate: Publicly trusted CA, 2048-bit RSA minimum
- Implementation: Azure Application Gateway (WAF enabled)
- HSTS: Enabled (max-age=31536000, includeSubDomains)
 
### Internal Communications (Organizational Network)
- Application to Database: TLS 1.2 (SQL Server native encryption)
- Service to Service: TLS 1.2 minimum (mutual TLS for high-sensitivity APIs)
- Rationale: Organization network provides baseline security; TLS adds defense-in-depth
 
### Non-Encrypted Channels
- Health check endpoints: HTTP permitted (no sensitive data)
- Internal monitoring: Unencrypted metrics (aggregate data only, no PII)

Encryption at Rest

## Data Protection at Rest
 
### Database Encryption
- Technology: Azure SQL Transparent Data Encryption (TDE)
- Algorithm: AES-256
- Key Management: Azure Key Vault (HSM-backed)
- Key Rotation: Annual (automated)
- Backup Encryption: Enabled (same key as primary)
 
### File Storage Encryption
- Technology: Azure Storage Service Encryption (SSE)
- Algorithm: AES-256
- Key Management: Microsoft-managed keys
- Rationale: Confidential data stored in database only; file storage contains public/internal data
 
### Application Secrets
- Technology: Azure Key Vault
- Contents: Database connection strings, API keys, certificate private keys
- Access: Managed identity only (no static credentials)
- Rotation: Quarterly for API keys, annually for certificates
 
### Unencrypted Data
- Application logs: Unencrypted (PII/sensitive data masked before logging)
- Rationale: Performance overhead vs. risk (logs don't contain sensitive data in clear text)

Key Management

Document key management practices:

## Cryptographic Key Management
 
### Key Lifecycle
- Generation: Azure Key Vault HSM (FIPS 140-2 Level 2)
- Storage: Key Vault (keys never leave HSM)
- Usage: Applications request encryption/decryption operations (keys never exposed)
- Rotation: Annual for data encryption keys, quarterly for application secrets
- Destruction: Key marked for deletion, 90-day recovery period, permanent deletion
 
### Access Control
- Key Access: Managed identity only (no user access to keys)
- Key Administration: Security team (create/rotate/delete keys)
- Emergency Access: Break-glass procedure requiring CISO + IT Director approval
 
### Key Escrow
- Backup: Key Vault backed up to secondary region (geo-redundant)
- Recovery: Disaster recovery procedures include key recovery testing
- Legal Hold: Keys retained beyond rotation if data subject to legal hold

Monitoring and Audit

Access control and data protection require monitoring to verify they work as designed:

## Access Control and Data Protection Monitoring
 
### Monitored Events (forwarded to SIEM)
- Authentication: All attempts (success and failure), lockouts, MFA failures
- Authorization: Access denied (user attempted unauthorized action)
- Data Access: Confidential data queries, bulk data exports, administrative queries
- Privilege: All privileged operations, role assignments, permission changes
- Encryption: TLS connection failures, certificate errors, key usage anomalies
 
### Alerting Thresholds
- Critical: 10+ failed auth attempts from single user in 5 minutes (potential brute force)
- Critical: Confidential data export >1000 records (potential data exfiltration)
- High: Privilege escalation outside business hours (unusual administrative activity)
- Medium: TLS 1.0/1.1 connection attempts (deprecated protocol usage)
 
### Audit Log Retention
- Authentication/Authorization Events: 1 year online, 7 years archived
- Data Access Logs: 1 year online, 7 years archived (regulatory requirement)
- Administrative Actions: 3 years online, 7 years archived

Common Mistakes and How to Avoid Them

Mistake 1: Generic Statements ❌ “System implements strong authentication” ✅ “System requires Azure AD SSO with MFA; session timeout 30 minutes; administrative access requires CyberArk elevation”

Mistake 2: Missing Authorization Matrix ❌ “System uses RBAC with roles: User, Admin” ✅ Documented permission matrix showing exactly what each role can do

Mistake 3: Incomplete Encryption Documentation ❌ “Data encrypted at rest” ✅ “Database: Azure SQL TDE with AES-256, keys in Key Vault; File storage: Azure SSE; Application logs: unencrypted (PII masked)”

Mistake 4: No Compensating Controls ❌ System can’t implement required control, not documented ✅ Standard control documented, technical limitation explained, compensating control defined, residual risk accepted

Mistake 5: Missing Review Process ❌ Access control documented, no ongoing review ✅ Quarterly access review process, role assignment approval workflow, audit log monitoring all documented

Conclusion

Access control and data protection appear in every security concept. Getting the details right makes the difference between useful documentation and compliance theater.

Document authentication requirements, not implementation. Specify authorization models with role definitions and permission matrices. Classify data and define handling requirements. Specify encryption algorithms, key management, and what isn’t encrypted.

The goal: enough detail to enable design review, audit testing, and knowledge transfer without overwhelming readers with implementation specifics. Balance depth with usability.

Article 7 provides practical implementation guidance: document structure templates, getting started with first security concept, scaling to portfolio of systems, common pitfalls, and success patterns from organizations doing this well.

Next in series: Article 7 - Implementation Guide: Templates, Tools, and Getting Started

Article 6 of 7 | Ready for publication Target audience: Security Architects, System Architects, Technical Security Specialists Word count: ~2,350

Graph View

Backlinks