Securosys365 - Definitions
Tenant
A tenant is the top-level container for managing cryptographic keys. It typically represents an entire organization rather than an individual. Each key, vault, and application in Securosys365 belongs to exactly one tenant. Tenants are completely isolated from each other.
⚠️ Important: Keys, vaults, and applications cannot be moved between tenants. Multiple tenants are possible if you're certain that objects won't need to be shared or moved across them.
Organization Unit
An Organization Unit in Securosys365 corresponds to a business unit or department within a tenant. It represents a subdivision of an organization and is not tied to any specific user. Each vault belongs to one organization unit. Like tenants, organizations are isolated from each other.
✅ Note: Unlike tenants, vaults and applications can be reassigned between different organization units. Therefore, you can create multiple organizations within a tenant more flexibly.
Users
Users are identified by their email addresses. A single user can belong to one or more organization units within a tenant.
For example, an employee may belong to:
- A production organization unit
- A testing organization unit
- A personal development account
Depending on the user's role and assigned permissions, they can:
- Manage users and vaults
- Create keys
- Modify key properties
- Review activity logs
🔐 Note: Users cannot perform cryptographic operations themselves—only registered applications can execute those operations.
Roles
Securosys365 comes with a set of predefined roles per tenant, which can be customized independently to suit organizational needs:
| Role | Description |
|---|---|
| DKE-Services | Used by the DKE Web Service (e.g., Microsoft 365 Office Applications) to perform cryptographic operations. This role is limited to operational use and cannot perform administrative tasks such as user management or Vault access configuration. |
| Securosys365 – Host | Reserved for Securosys personnel responsible for tenant-level administration and support. |
| Securosys365 – Tenant Admin | Customer administrator, has administrative rights within the tenant. This role can access the Securosys365 DKE Cockpit, create DKE Keys and Web Services, and manage users and groups. |
| Securosys365 – Auditor | A read-only role with access to view keys, services, and audit/activity logs. Ideal for compliance or monitoring purposes. |
Keys
A Key is stored within a Securosys CloudHSM Partition (Vault) and represents either a symmetric key or an asymmetric key pair. For asymmetric keys, both the private and public components are stored together in a single Key object. In some cases, such as when generating an RSA key in an HSM, a Key may contain only a public key without an associated private key.
Each Key belongs to exactly one Vault. Access to a Key is governed by the permissions assigned to the Vault it resides in. Users and applications that have access to the Vault can view and operate on its Keys.
🔐 Note: Users or applications not assigned to the Vault cannot see or interact with its Keys. For more details, see the Authorization section.
Key States
The Key states conforms with NIST SP800-57 - Recommendation for Key Management - Chapter 7 Key States and Transitions
| State | Description |
|---|---|
| PreActive | Key is generated on the HSM but is not yet active. If a Activation time constraint is given. If the action time is reached the key will automatically receive the state Active based on the timezone settings (default: W. Europe Standard Time). |
| Active | The key can be used for cryptographic operations and is the default state. |
| Deactive | Key cannot be used for new encrypt operations but still needed to decrypt (e.g. old encrypted files) |
| Compromised | Key known or suspected to be compromised. This key should never be used again (thus you cannot reactivate this key, once it is compromised). Generally, keys are compromised when they are provided to or determinded by an unauthorized entity. |
Important:: Keys which are in state Deactivated or Compromised cannot be re-activated!
reference: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf - Chapter 7 Key States and Transitions
Vaults
A Vault is a logical container for grouping related Keys. All Keys in a Vault inherit the same Access Policies and Approval Policies, which are defined at the Vault level.
- Multiple users and applications can be granted access to a Vault.
- Vaults serve as the security boundary for key access and operations.
- By default, Securosys is setting up at least one dedicated vault (KeyStore) on a CloudHSM Partition for each Tenant. If more vaults are needed, please contact your sales representative, or open a request on the Securosys Support Portal.
Apps (DKE Web Service)
An Application refers to a non-human client—such as a service, daemon, or background process—that interacts with Securosys 365. Applications (Mircosoft365 Office Applications) authenticate to Securosys365 using either:
- An API key (secret token)
Depending on assigned permissions, applications can:
- Create Keys
- Modify Key properties
- Perform cryptographic operations using Keys
⚠️ Note: Applications cannot perform administrative tasks such as managing users or assigning access to Vaults.
An application can be assigned to one or more Vaults. Once assigned, it gains permission to operate on all Keys within those Vaults.
Conditional Access Policy (Authorization)
Conditional Access Policy enables fine-grained authorization for operations on entities such as Vaults, Keys, and Applications (Apps).
Starting from version 1.0, Securosys365 supports detailed access controls that define what actions an App can perform within each organization unit it is associated with. An App is linked to a Vault, which in turn is linked to one or more organization units.
In addition to assigning specific Key Operations to security objects, administrators can assign operation-level permissions to groups that an App belongs to.
When an App interacts with a Vault or Key, the following security controls apply:
- Quorum Control (coming soon) – Allows enforcement of multi-party approvals.
- Role-Based Access Control (RBAC) – App permissions are defined via roles assigned to it.
- Conditional Access Policies – Fine-tuned rules that govern what the App can do, based on its context and assigned permissions.
- Status Control – Apps can be explicitly enabled or disabled, impacting their ability to perform operations.
Conditional Access Policy
The fine-grained authorization model in Securosys365 is inspired by Microsoft Azure Conditional Access Policies. These policies operate on simple if-then logic:
If a user or application attempts to access a resource (such as a Vault, App, or Key), Then specific conditions must be met—for example, requiring multi-factor authentication (MFA).
Commonly Applied Conditional Access Policies
Here are some widely used policies that organizations implement:
- Require MFA for users in administrative roles
- Enforce MFA for high-impact operations, such as editing or deleting sensitive data
- Block access from unregistered or unmanaged devices (Device Trust)
- Require access from trusted network locations for DKE365 encryption/decryption
- Restrict or allow access based on geographic location
- Block access based on risky sign-in behaviors, such as impossible travel or anonymized IPs