This article explains Accounts/ Profile interrelations, Trust associations and the role of Server Sets.
Summary/ Requisite Review
SSProtect functions in the context of an Account exclusively identified by a Username, which is an email address that you control and choose to associate with SSProtect during provisioning.
Accounts operate in the context of an Organization, which is a collection of Accounts that share common administration and inherent Trust associations. An Individual Account is a special case that maintains a hidden association with an Organization, operating without the complexity of administrative controls. The Organization Name, in this case, matches the Account Username (its' email address).
Trust associations govern access to SSProtect-managed content: You can always access content you, "own", and also content, "owned" by other Accounts in your Organization. Note however that shared content is not delivered by SSProtect: Protect data files then utilize them with the usual collaboration tools and facilities. SSProtect is required to access the resulting ciphertext content, since protections follow data.
"Ownership" serves a limited purpose in SSProtect, associating a managed item with the Account first adding protection to an item (for example using the File Explorer's SSProtect Activate context menu). Subsequent attempts to access content yield encrypted/ obfuscated content. When SSProtect is present, the software intercepts access attempts then authenticates and authorizes access by on, "ownership" and Trust associations. This process, denoted as In-Place Encryption, is described in the article, Protecting and Working with Files.
Organizations are managed by a single Administrator and one or more assigned Delegates. Privileged Users can control Account configuration, active components, policies, and other operational features.
In short:
- Use of SSProtect is identified by a unique Account you use for Login
- You create your Account the first time you run the software
- Account Usernames utilize the address of a working email account
- An Account can be a member of an Organization, or an Individual Account
- Organizations logically group Accounts, often defined by teams in a Company
- Administrators and Delegates manage Organizations and their Account settings
- Administrators and Delegates can create Accounts, generating Registration Email
- Accounts in the same Organization can, by default, access shared managed content
- Third Party Trust associations implement Policy for data sharing outside an Organization
Zero-Config Secure Sharing
:Collaborate is the SSProtect component responsible for managing Trust relationships. It is always enabled, for every Account, and an integral part of the system.
:Collaborate provides access to shared, managed content when two Accounts have a Trust relationship. All members of a single Organization, by default and at all times, maintain mutual Trust with one another. This allows Organization members (Accounts/ Users) to share protected content without additional configuration.
Accounts that are members of other Organizations cannot access shared, protected content without being given specific permission (see below). As a result, companies often choose to deploy multiple SSProtect Organizations for different internal Teams, isolating content and protecting against internal malice.
Internal teams, however, often share content. This can be managed with Third Party Trusts, explained below.
Secure Sharing with Third Party Trusts
Accounts from two different Organizations can only share data when configured as Third Party Trusts. This is a one-way association that allows a single Organization to extend secure data sharing access to a single external Account. This can be setup, "the other way" by the remote Administrator (or Delegates) to create a bi-directional data sharing arrangement.
Third Party Trusts are compatible with both Organization and Individual Accounts. Each association can be temporarily disabled or revoked at any time, and the impact is immediate. Different encryption modes, or Operating Modes, affect related services in ways further described in Protected Data Sharing and Managing Third-Party Trusts.
KODiAC Cloud Server Sets
A Server Set, in the SSProtect sense, is a collection of cloud server resources that host KODiAC Cloud Services and respond to requests from SSProtect-enabled host computers. This is better described in the article, System Overview, though it's important to know that KODiAC Cloud Services participate in every transaction, managing patented cryptographic offloading operations that reduce data disclosure risks, maintain detailed audit records, and improve the accuracy of resulting :Assess Usage Reports and :Respond Analysis operations.
Server Sets are deployed in highly-available clusters, geographically distributed to maintain accessibility. We typically refer to Server Sets using a single (FQDN) name.
Server Set details are critical when you plan to manage your own KODiAC Cloud Service deployment and/ or want to maintain close control over data storage policies (locations). For more information, refer to the article, KODiAC Replication.
The default KODiAC Server Set association is ssp.kodiac.io. Make certain participating hosts maintain outbound connectivity to this egress target, TCP ports 52522/ 52622. Load balancing, DNS, and KODiaC Replication Policies handle the rest for you.
NOTE: ssp.kodiac.io does not utilize fixed/ static IP addresses, and as a result you should not configure egress policies that rely on DNS Resolver IP address results.
Email Addresses and SSProtect Identity
Organizations contain a unique set of Accounts and thus a unique set of Usernames. Usernames are unique within and across Organizations, globally - unless you are hosting an isolated KODiAC Server Set deployment of your own.
Multiple Account Use
You can only use a single email address with multiple SSProtect Accounts but only when they are provisioned with independently-operated KODiAC Server Set interconnections. All DefiniSec-managed Server Sets interconnect globally, and as a result, you can only use an email address once with any DefiniSec-managed KODiAC Server Set.
If at a later time you deploy your own isolated KODiAC Server Set distribution(s), you would be able to provision an Account using the same email address. This is one of the ways Profiles can be useful, as noted in the next section.
CAUTION: We do NOT recommend using the same email address for multiple Accounts, except by advanced users very familiar with system use. This can be quite confusing when, for example, using :Email and trying to determine why a particular incoming protected message can't be opened. In such cases, it often comes down to the context the managing Account is using - and when incoming data is from an Account associated with a different set of Global Server Sets, expectation won't align with reality.
Profiles
To simplify Login, we have created Profiles to represent the combination of Username (email address), Account, Organization, and Server Set. This is a unique combination which is more easily referred to by a single moniker, i.e., "Work" or, "Home". You can gain more insight into how Profiles function by following the procedure outlined in the article, Registering a 2nd Profile.
Additional Resources
You can search this site for more information on various topics, or use this link to submit a specific request. You can also send email directly to support@definisec.com, and our staff will respond to your needs as soon as possible.
In the meantime, don't forget to check out our primary website and Insights columns for information on current trends, security topics, and how our technologies relate.
This article was updated w/ v10.9.4 of the :Foundation Client