Digital transformation, and specifically the adoption of cloud apps and infrastructure, has rapidly reshaped the corporate tech landscape. While some companies have been built in a cloud-first way and are “cloud native,” many organizations still operate in hybrid tech stack environments. This guide will look at some of the various environments we see across companies today and how ConductorOne connectors can integrate with, and protect identity and access for, any application and architecture.
Types of environments
Depending on industry, size, and where a business is in the digital transformation and cloud adoption maturity curve, companies have varying degrees of complexity in their technology environment. These can very broadly fit into three buckets:
Fully on-premises architecture
Organizations with stringent security or regulatory needs may opt to keep all their systems on-premises or hosted in a private cloud (on-prem). This means that all the necessary infrastructure and services are installed and maintained on the company’s servers or private cloud infrastructure and managed by IT, security, and DevOps teams.
Hybrid architecture
Most large enterprises operate through a blend of on-premises and cloud-based systems. They may have several critical systems that they manage and control in their own infrastructure, using technologies such as access gateways or VPNs to bridge the access gap for these systems. They may also have adopted one to many SaaS or public cloud providers as well. These environments are particularly tricky as they usually retain multiple identity directories, or “sources of truth,” across on-prem directory stores, such as Active Directory, and cloud directories such as cloud HR systems or a cloud IdP.
Cloud-native architecture
Cloud-native companies use all cloud applications and infrastructure. These organizations design, build, and deploy their applications to take full advantage of the cloud’s elasticity, scalability, and speed. Generally these companies are “younger,” to wit, started and built in the last few years, when the availability of cloud SaaS and infrastructure providers was prolific enough to provide all of the necessary tooling to run a business. These organizations enjoy benefits such as lower operational costs and improved agility that come from being on a cloud-native architecture.
Connecting to any application or technology
ConductorOne has a range of options to connect our identity security platform directly to a customer’s environment – regardless of whether the apps, directories, and infrastructure are in the cloud or hosted within the customer’s environment. ConductorOne achieves this by enabling a hybrid agentless + agent approach for connecting to the ConductorOne service. “Managed connectors” is the term we use to describe the agentless deployment of connectors that interface with cloud apps and infrastructure. “Self-hosted connectors” is the term we use to describe deploying a connector alongside the technology in question, within the customer’s environment. Let’s get into more detail.
Managed connectors
Managed connectors are agentless and deployed directly from the ConductorOne service. These connectors are built and maintained by ConductorOne and are easily set up and configured via the ConductorOne web console or Terraform. A list of supported connectors can be found here. With managed connectors, the user inputs the necessary credentials to connect the ConductorOne service to the SaaS, IaaS, or directory in question. Once authorized, these connectors provide a full inventory of identities, groups, and access rights from the service. ConductorOne uses this data, and the authorized credentials, to automate identity security workflows and access management such as provisioning and deprovisioning. Data from connected services is automatically synced and the administrator does not need to worry about connector maintenance or scheduling.
Self-hosted connectors
Connectors can also be self-hosted, that is, hosted within the customer’s on-prem, private cloud, or public cloud environments. Self-hosting provides several capabilities not offered from managed connectors, namely:
- Control over credentials: With self-hosted connectors, the ConductorOne service does not have access to the credentials used for authorization to the connected service.
- Granular auditing: Self-hosted connector actions can be granularly audited and recorded beyond what is provided by the ConductorOne service.
- Connectivity to non-internet exposed services: Self-hosted connectors can be deployed in an agent-like model. This allows them to run alongside and communicate with services that are on-prem, in private clouds, or otherwise inaccessible from the ConductorOne service.
- Control over sync schedule: Self-hosted connectors allow for flexibility and deeper configuration of how often and what data is ingested.
- Support for custom apps: ConductorOne provides an open-source software development kit (the Baton SDK) that can be extended to connect to non-off-the-shelf software such as support portals or homegrown apps.
ConductorOne provides open-source versions of our managed connectors through a project called Baton. Baton connectors for SaaS, IaaS, and cloud directories are the same as the managed connectors provided through the ConductorOne service. However, because they are open source, companies can extend them and deploy them as self-hosted connectors for the aforementioned benefits.
Certain connectors must be self-hosted due to the nature of the technology that is being connected to the ConductorOne service. For instance, a PostgreSQL database or Active Directory instance needs direct connectivity and requires the use of a self-hosted connector. These connectors can be found in the Baton open-source directory.
On demand vs. service mode
A unique attribute of self-hosted connectors is that they can be run in different modes. As the customer has complete control over how and when these connectors run, this can provide useful flexibility. The two modes of operation are:
- On demand: In this mode, the connector does not run continuously. Rather, it runs in a single “shot” where data is extracted and can be either automatically uploaded to the ConductorOne service or manipulated manually from a .c1z output file.
- Service mode: This mode is functionally equivalent to managed connectors. In this mode, the connector is run continuously as a service. The connector runs as if it were a managed connector in the ConductorOne service, but it is simply hosted in the customer’s infrastructure.
Some connectors require user interaction for opening a connection, such as requiring the user to provide two-factor authentication. In such cases, the connector may still be provided by ConductorOne but will require self-hosting and will run on demand as needed.
Direct data ingestion
In addition to connectors, which automate the process of synchronizing identity security data and orchestrating workflows, ConductorOne also supports various direct data ingestion capabilities. These include:
S3 bucket
With this method, the ConductorOne service ingests data from an S3 bucket. The customer is responsible for pushing and updating the data in the S3 bucket, and can do so however they see fit. The ConductorOne service monitors this bucket continuously and will update the data reflected in the service upon update. Data can be formatted in a .csv, .xslx, or .c1z file format.
Manual data upload
Data from the application is ingested through a manual .csv, .xlsx, or .c1z file upload. The ConductorOne service supports varying file formats as a file mapping can be specified and reapplied to subsequent uploads of the data.
Building your own connector
Many companies have homegrown or back office tools that are essential to secure. In such cases, customers can build their own connector with the Baton SDK. Read the Baton SDK getting started guide to learn more. Once built, these connectors can be integrated directly with the ConductorOne service using the self-hosted connector deployment model.
Evaluating support for your environment
When considering an identity security solution, it’s important to evaluate how your environment will be supported. Keep in mind and consider:
- Off-the-shelf support: How many of your SaaS, IaaS, directories, and infrastructure tools does the solution provide off-the-shelf connectors for?
- Support for hybrid or on-prem systems: Does the solution support hybrid cloud or on-prem technologies such as Postgres, LDAP, Active Directory, and so forth?
- Deployment flexibility: Does the solution allow for flexible connector deployment in the case of sensitivity of sharing credentials?
- Scalability: Can the solution scale to support your environment size and user counts?
- Back-office portal and custom apps: Can the solution support non-COTS (commercial off-the-shelf), non-SaaS software?
- Support and maintenance: Does the provider have robust customer support and regular maintenance?
With a holistic view of your environment, you can identify and remediate identity-centric threats proactively.
Conclusion
Identity and access control is complicated, and especially so for hybrid IT environments that combine cloud and on-prem apps. At ConductorOne, we recognize that identity is both messy and hard, but getting it right and securing it is paramount to preventing breaches and customer data loss. ConductorOne’s comprehensive connector catalog and deployment options are designed to support customers of all environments, allowing for unified identity security, reduced costs, and streamlined compliance.
