Simplified Usage-Based Pricing 

Ionic Machina™ delivers real-time data policy enforcement against a rich set of identity (user, device, service) and data attributes, backed by machine-scale key management in a single unified solution. 

Data policies allow enterprises to create rules to define how data is accessed and handled across your hybrid or single/multicloud environment. Every piece of data that is protected by Machina gets its own unique encryption key. The default keyspace provisioned for new customers can hold a trillion keys for this purpose. Each decision, whether to protect new data, to change what we know about the data, or to request access counts as a transaction. For scalability, we also allow (and encourage) batch transactions. In each case, a transaction is incurred for each discrete piece of protected data, whether it is requested in batch or individually.

Ionic makes it as easy as possible for you to implement granular and contextual attribute-based access control (ABAC) policies across your organization. Machina uses several API calls in the process of making a policy enforcement decision. You may be familiar with several other security solutions that charge by the number of API calls made, but to simplify usage metrics for billing, Ionic only charges for transactions that provide customer value -- number of policy decisions enforced. 

Policy Decision Transactions 

Policy decisions, whether requested individually or in batch, are rendered against unique (and generally fine-grained) items, like a piece of protected data. It is the pairing of a decision to an individual item that counts as a transaction for billing purposes. Each policy decision -- allow, deny, modify and protect, has a unique entry in the Analytics section of Machina Console (Fig. 1), with several additional details to describe it. The columns of interest for this calculation are DECISION (what type of decision has been rendered) and DATA KEY ID (the individual item the decision was rendered against).

The following process flow leads to policy decision transactions that are used for billing: 

• Policy rules are created using the rich identity and data attributes to render allow/deny access decisions, modify data attributes, or protect a new item
• Every discrete allow, deny, modify, and protect request is considered a policy decision and is identified by a unique ID when rendered (see DATA KEY ID column in Fig. 1)
• A decision/data key ID pair is considered a policy decision transaction
• The total number of transactions across your organization is used for periodic billing

Fig. 1: Policy decisions made on individual key IDs

Rendered decisions are represented in the console, providing you full visibility into how data is handled across your organization. The total number of policy decision transactions is represented by the number of unique decisions and data key ID pairs captured under Analytics > Metrics (Fig.2)

Fig. 2: Unified view of all policy decision transactions across your organization

You can click on any of the policy decision transaction metrics to see additional details. Select/hide columns to customize the output.

Fig. 3: List of all transactions under a specific policy decision metric