Securosys365 - RBAC
Intro
Securosys 365 Double Key Encryption (DKE) enhances security protocols by implementing an advanced Access Control Policy feature. This feature integrates Role-Based Access Control (RBAC) capabilities, allowing fine-grained control over the usage of DKE keys based on user-defined policies.
What is Access Control Policy for Securosys 365 DKE
The Access Control Policy for Securosys 365 DKE is designed to provide organizations with the ability to control and restrict the use of encryption keys based on predefined roles and attributes. This feature is pivotal for organizations seeking to implement stringent security measures to protect sensitive information from unauthorized access.
Core Principles of Zero Trust Implemented in DKE 365
Zero Trust is a security model that requires strict identity verification for every person and device trying to access resources on a private network, regardless of whether they are sitting within or outside of the network perimeter. This principle aligns perfectly with the need to protect sensitive data in environments such as Microsoft 365, where data might be accessible from a multitude of locations and devices.
Securosys DKE 365 integrates this model by ensuring that:
- No implicit trust is granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet).
- Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established.
Supported Access Control Policies
The system supports various levels of control to enhance the security of DKE key usage:
- User Restriction: Allow or block specific User Principal Names (UPNs), effectively controlling which user(s) can access encryption keys.
- Device Restriction: Include or exclude access based on source IP addresses, ensuring that only devices from secure and recognized IPs can request key access.
- Geographic Restriction: Control access based on the geographic location of the request, enhancing compliance with national data protection regulations.
- Group Management: Integrate with Azure AD to allow or block access based on group membership, simplifying the administration of access rights across large user bases.
Architecture and Component Description
The Securosys365 DKE consists of the following system components:
- DKE Console (Cockpit): Central hub for configuring and managing access control policies.
- DKE Web Service API (Application Layer): Interfaces with Microsoft environments to manage encryption and decryption processes.
- Policy Enforcer (Security Layer): Validates access requests against configured policies, ensuring compliance before allowing key decryption.
- DKE Cryptographic Service (CloudHSM): Enable secure generation and storage of DKE service keys inside HSMs for the unwrapping of document encryption keys.
The DKE Console (Cockpit) allows administrators to create, modify, and delete DKE keys and Access Control policies. It also provides logging and reporting features. The DKE keys are generated and stored on physical HSMs provided by the DKE Cryptographic Service of Securosys CloudHSM. Customer Microsoft Office Client users interact with the DKE Web Service API (or DKE App) which processes encryption and decryption requests, interfacing with the Policy Enforcer to validate access rights.
The Policy Enforcer uses JWT claims to evaluate and enforce access policies dynamically. It operates based on real-time data, including user identity, device location, and group membership. It is embedded on the DKE Web Service API (DKE App) and DKE Console (Cockpit).
Policy Enforcement:
Casbin policies define who can access what resources, under which conditions. These policies are stored in a flexible and maintainable format, making it easy to update rules as organizational needs evolve.
The engine evaluates the context of each access request, such as the user’s location, the device state, and membership in specific Azure AD groups, to make real-time decisions about whether to allow access to a decryption key.
Secure Content Key Decryption:
When a user attempts to access an encrypted document in Office 365, DKE 365 intercepts this request to determine if the user should be granted access.
The access control engine consults the policy defined in Casbin, evaluates the user’s context, and either permits or denies the decryption key based on the policy’s criteria.
Security Targets and Protection Goals
The Access Control Policy addresses several critical security targets:
- Prevention of Unauthorized Access: By enforcing strict access control policies outside Azure portal, the system prevents unauthorized users and devices from accessing sensitive encrypted data.
- Compliance with Regulatory Requirements: It supports compliance with various data protection laws by ensuring that data access controls meet specified standards.
- Enhanced Data Security: It protects sensitive information from data breaches by ensuring that only authorized entities can decrypt data.
The system directly contributes to the protection goals outlined in the Microsoft Double Key Encryption – Planning and Deployment Considerations whitepaper, including:
- Enhanced Privacy and Data Sovereignty: By allowing organizations to manage their encryption keys, it ensures that no third party, not even cloud service providers, can access sensitive information without authorization.
- Robust Data Security Architecture: The separation of duties and layered security architecture minimize the risk of internal threats and unauthorized data access.
The specific Security Model enhancements are designed to address the objectives outlined in the threat model, including:
- Model A (DKE Network Isolation): It ensures the isolation and protection of data, by deploying the DKE service in dedicated network segments.
- Model B (Keystore Protection from Internal IT Staff and Hosting CSP): Keys are managed in an environment isolated from internal and cloud provider access, secured in hardware or cloud-based HSMs (Securosys CloudHSM).
- Model F (Vendor HSM): Even without the Access Policy feature, Securosys365 DKE, integrated with Securosys CloudHSM, offers a robust HSM solution that securely stores encryption keys, ensuring protection against unauthorized access and potential loss.
| Asset | Threat | Mitigation Strategy |
|---|---|---|
| Encryption Keys | Unauthorized Access | Granular access controls based on roles, IP, location, and group membership. |
| Insider Threats | Role-Based Access Control (RBAC) and strict policy enforcement to limit access based on necessity. | |
| User Data | Spoofing Identity | Robust authentication mechanisms and dynamic policy enforcement based on JWT claims. |
| Data Exfiltration | Data encrypted at all times; keys are managed in HSM and accessed based on strict policies. | |
| Access Control Policies | Policy Tampering | Audit trails and logging of all access and policy changes can be pushed to Splunk; regular policy reviews and updates. |
| System Integrity | Denial of Service (DoS) | System redundancy and failover capabilities to ensure availability; rate limiting and monitoring. |
| Malware and Attacks | Continuous monitoring, anomaly detection, and implementing least privilege access. |
Confiugre RBAC
Login into the Securosys365 - DKE
- Login to Securosys365 - DKE Cockpit
Create RBAC Policy
- In the Administration Tab open Securosys365 - DKE: Access Control Policy
Create new Access Control Policy
- Click Create New Access Policy.
- Enter Conditional Access Policy name
- Select an Action > Allow
- Select the Organisation Unit
Now Fill the details to create the access control policy as per the requirements.
You can choose what type of access policy needs to be applied by selecting the Different Tab and filling the mandatory fields. You need to select Action like Allow/Block/By-pass
Actions
The following example lets any user with an given email address and Upn, to reach the application:
| Action | Rule Type | Selector | Value |
|---|---|---|---|
| Allow | Any Of | dke-rbac-tester1@securosys.com | |
| Allow | Contains | Upn | dke-rbac-tester2@securosys.com |
Block
For example, this configuration blocks every request to the application that tries to login with the IP Address
- Include: IP Only (Brazil: 101.33.22.0),
- except the IP Only (Australia: 1.178.144.0)
| Action | Rule Type | Device | Value |
|---|---|---|---|
| Block | Include(IP Only) | IP Only | Brazil: 101.33.22.0 |
| Block | Exclude(IP Only) | IP Only | Australia: 1.178.144.0 |
Bypass
The Bypass action allow all access requests and will not verify any policy rule.
User
Device
Location
External Group
To Create the Identify Provider For Azure AD for External Groups, Follow the setup instructions here: Setup Identity Provider
After filling the required Data Click on the Save Button. Access Control Policy is created successfully and start displaying under the grid as shown below:
Apply RBAC Policy to DKE Web Service (App)
- Open the Tab Apps Securosys 365 - Apps
- Select the App you whish to enforce the newly generated RBAC Policy
- Click Actions
- Select Edit
- Click three times Next unitl you see Your DKE Access control policy
- Select your RBAC-Policy
- Finish the DKE-App Wizard
The RBAC Policy is immediately applied to DKE-Decrypt Requests when Submitting the configuration.
