Protegrity AI Team Edition

• 1: Introduction to Protegrity AI Team Edition
• 2: Overview of Protegrity AI Team Edition
• 2.1: Architecture and Design Principles
• 2.2: Protegrity Common Services
• 2.3: Compatible Features
• 3: Infrastructure
• 3.1: Preparing for Protegrity AI Team Edition
• 3.2: Configuring Authentication for Protegrity AI Team Edition
• 3.3: Protegrity Provisioned Cluster
• 3.3.1: Installing PPC
• 3.3.1.1: Prerequisites
• 3.3.1.2: Preparing for PPC deployment
• 3.3.1.3: Deploying PPC
• 3.3.2: Accessing PPC using a Linux machine
• 3.3.3: Installing Features and Protectors
• 3.3.4: Login to PPC
• 3.3.4.1: Prerequisites
• 3.3.4.2: Log in to PPC
• 3.3.5: Accessing the PPC CLI
• 3.3.5.1: Prerequisites
• 3.3.5.2: Accessing the PPC CLI
• 3.3.6: Deleting PPC
• 3.3.7: Restoring the PPC
• 3.4: Working with Insight
• 3.4.1: Overview of the dashboards
• 3.4.2: Working with Discover
• 3.4.2.1: Understanding the Insight indexes
• 3.4.2.2: Understanding the index field values
• 3.4.2.3: Index entries
• 3.4.2.4: Log return codes
• 3.4.2.5: Protectors security log codes
• 3.4.2.6: Additional log information
• 3.4.3: Viewing the dashboards
• 3.4.4: Viewing visualizations
• 3.4.5: Index State Management (ISM)
• 3.4.6: Backing up and restoring indexes
• 3.4.7: Working with alerts
• 3.5: Protegrity REST APIs
• 3.5.1: Accessing the Protegrity REST APIs
• 3.5.2: View the Protegrity REST API Specification Document
• 3.5.3: Using the Common REST API Endpoints
• 3.5.4: Using the Authentication and Token Management REST APIs
• 3.5.5: Using the Policy Management REST APIs
• 3.5.6: Using the Encrypted Resilient Package REST APIs
• 3.5.7: Roles and Permissions
• 3.6: Protegrity Command Line Interface (CLI) Reference
• 3.6.1: Administrator Command Line Interface (CLI) Reference
• 3.6.1.1: Configuring SAML SSO
• 3.6.2: Using the Insight Command Line Interface (CLI)
• 3.6.2.1: Sending logs to an external security information and event management (SIEM)
• 3.6.3: Policy Management Command Line Interface (CLI) Reference
• 3.6.3.1: Using the Policy Management Command Line Interface (CLI)
• 3.7: Troubleshooting
• 3.8: Replacing the default Certificate Authority (CA) with a Custom CA in PPC
• 4: Governance and Policy
• 4.1: Protegrity Policy Manager
• 4.1.1: Prerequisites for Installing the Policy Workbench
• 4.1.2: Installing Policy Workbench
• 4.1.3: Uninstalling the Protegrity Policy Manager
• 4.1.4: Backing up the Policy Workbench
• 4.1.5: Restoring the Policy Workbench
• 4.1.6: Workbench Roles and Permissions
• 4.1.7: Troubleshooting the Protegrity Policy Manager
• 4.2: Protegrity Agent
• 4.2.1: Prerequisites
• 4.2.2: Roles and Permissions
• 4.2.2.1: Required Roles and Permissions
• 4.2.2.2: Working with Roles
• 4.2.3: Installing Protegrity Agent
• 4.2.3.1: Installing Protegrity Agent
• 4.2.4: Configuring Protegrity Agent
• 4.2.5: Using Protegrity Agent
• 4.2.5.1: Accessing Protegrity Agent UI
• 4.2.5.2: Working with Protegrity Agent
• 4.2.5.3: Samples for using Protegrity Agent
• 4.2.6: Uninstalling Protegrity Agent
• 4.2.7: Appendix - Features and Capabilities and Limitations
• 4.2.8: Appendix - Backup and Restore
• 4.3: Sample Protection Workflows
• 4.3.1: Policy Workflow
• 4.3.1.1: Initialize Policy Management
• 4.3.1.2: Prepare Data Element
• 4.3.1.3: Create Member Source
• 4.3.1.4: Create Role
• 4.3.1.5: Assign Member Source to Role
• 4.3.1.6: Create Policy Shell
• 4.3.1.7: Define Rule with Data Element and Role
• 4.3.1.8: Create Datastore
• 4.3.1.9: Deploy Policy to a Datastore
• 4.3.1.10: Confirm Deployment
• 4.3.2: Create a policy to protect Credit Card Number (CCN)
• 4.3.2.1: Initialize Policy Management
• 4.3.2.2: Prepare Data Element
• 4.3.2.2.1: Create Mask
• 4.3.2.3: Create Member Source
• 4.3.2.3.1: Test New Member Source
• 4.3.2.4: Create Role
• 4.3.2.5: Assign Member Source to Role
• 4.3.2.5.1: Synchronize Member Source
• 4.3.2.6: Create Policy Shell
• 4.3.2.7: Define Rule with Data Element and Role
• 4.3.2.8: Create Datastore
• 4.3.2.9: Deploy Policy to a Datastore
• 4.3.2.10: Confirm Deployment
• 4.3.3: Create a policy to protect Date of Birth (DOB)
• 4.3.3.1: Initialize Policy Management
• 4.3.3.2: Prepare Data Element
• 4.3.3.3: Create Member Source
• 4.3.3.3.1: Test the Member Source
• 4.3.3.4: Create Role
• 4.3.3.5: Assign Member Source to Role
• 4.3.3.5.1: Synchronize Member Source
• 4.3.3.6: Create Policy Shell
• 4.3.3.7: Define Rule with Data Element and Role
• 4.3.3.8: Create Datastore
• 4.3.3.9: Deploy Policy to Datastore
• 4.3.3.10: Confirm Deployment
• 4.3.4: Full Script Examples
• 4.3.4.1: Full Script to Protect CCN using Policy Management REST APIs
• 4.3.4.2: Full Script to Protect DOB using Policy Management REST APIs
• 5: Data Discovery
• 5.1: Prerequisites
• 5.2: Installing Data Discovery
• 5.3: Configuring Data Discovery
• 5.4: Uninstalling Data Discovery
• 5.5: Troubleshooting
• 5.6: Logging usage metrics
• 6: AI Security
• 6.1: Semantic Guardrails
• 6.1.1: Prerequisites
• 6.1.2: Installing Semantic Guardrails
• 6.1.3: Testing the Semantic Guardrails deployment
• 6.1.4: Configuring Semantic Guardrails
• 6.1.5: Uninstalling Semantic Guardrails
• 7: Data Privacy
• 7.1: Protegrity Anonymization
• 7.1.1: Prerequisites
• 7.1.2: Installing Protegrity Anonymization
• 7.1.3: Configuring Protegrity Anonymization
• 7.1.4: Protegrity Anonymization Python SDK Installation
• 7.1.5: Uninstalling and Cleanup Protegrity Anonymization
• 7.2: Protegrity Synthetic Data
• 7.2.1: Prerequisites
• 7.2.2: Installing Protegrity Synthetic Data
• 7.2.3: Configuring Protegrity Synthetic Data
• 7.2.4: Uninstalling and Cleanup Protegrity Synthetic Data
• 8: Protectors
• 8.1: Cloud Protector
• 8.2: Application Protector
• 8.2.1: Application Protector
• 8.2.1.1: Application Protector Java
• 8.2.1.1.1: Installing the Application Protector Java
• 8.2.1.1.2: Uninstalling the Application Protector Java
• 8.2.1.2: Application Protector Python
• 8.2.1.2.1: Installing the Application Protector Python
• 8.2.1.2.2: Uninstalling the Application Protector Python
• 8.2.1.3: Application Protector .Net
• 8.2.1.3.1: Installing the Application Protector .Net
• 8.2.1.3.2: Uninstalling the Application Protector .Net
• 8.2.2: Application Protector Java Container
• 8.2.2.1: Installing the Application Protector Java Container
• 8.2.3: REST Container
• 8.2.3.1: Installing the REST Container
• 8.3: Repository Protector
• 8.3.1: Amazon EMR Protector
• 8.3.1.1: Installing the Amazon Elastic MapReduce Protector
• 8.3.1.2: Uninstalling the Amazon Elastic MapReduce Protector
• 8.3.2: AWS Databricks Protector
• 8.3.2.1: Installing the AWS Databricks Protector
• 8.3.2.2: Uninstalling the AWS Databricks Protector
• 8.3.3: CDP-AWS-DataHub Protector
• 8.3.3.1: Installing the CDP-AWS-DataHub Protector
• 8.3.3.2: Uninstalling the CDP-AWS-DataHub Protector

1 - Introduction to Protegrity AI Team Edition

Protegrity AI Team Edition is a container-based data protection solution designed for teams and mid-enterprise organizations that need to safeguard sensitive data across AI, GenAI, and analytics workloads.

It delivers core Protegrity capabilities, including governance, discovery, protection, and privacy. This is provided in a lightweight, containerized form factor that emphasizes fast deployment, simplified operations, and consistent enforcement of data security policies across environments.

Built on a modular, microservices architecture, it moves away from the legacy appliance model to align with modern DevOps practices. The result is a deployment that scales easily, integrates natively with existing CI/CD pipelines, and supports governing agents and securing departmental data.

Purpose and Audience

Protegrity AI Team Edition is intended for:

• Organizations seeking to protect data used in AI or analytics pipelines.
• Teams that require fast deployment cycles and simplified upgrades.
• Customers who need enterprise-grade data protection in a form that can start small, operate independently, and later scale into Protegrity AI Enterprise Edition.

2 - Overview of Protegrity AI Team Edition

The Protegrity AI Team Edition introduces a modern, container-based approach to data protection built on a microservices architecture. It enables organizations to evaluate how Protegrity’s methods, such as, policy management, anonymization, discovery, and semantic controls, integrate into AI and analytics pipelines.

2.1 - Architecture and Design Principles

Protegrity AI Team Edition delivers core Protegrity capabilities. This includes governance, discovery, protection, privacy, and semantic controls. It is provided in a lightweight, containerized form factor that emphasizes fast deployment, simplified operations, and consistent enforcement of data security policies across environments. It is designed around five engineering goals: ease of deployment, high availability, scalability, extensibility, and maintainability.

2.2 - Protegrity Common Services

All deployments include a standardized set of common services delivered by a microservices architecture provide routing, security, and audit capabilities for all features and protectors.

2.3 - Compatible Features

The various features compatible with Protegrity AI Team Edition are provided here.

* - Available for purchase as an add-on. Can be installed as an individual product.

Protegrity Protectors

Protegrity AI Team Edition protectors enable organizations to embed data protection directly where data is processed, inside applications, analytics engines, or cloud-native data systems. The protectors use the Workbench for obtaining the policy for processing. The Protegrity Agent is available for creating and working with policies in the Workbench.

Application Protectors

Application protectors provide data protection directly within applications or runtime containers. They are suitable for teams developing secure APIs or microservices that handle sensitive data in languages such as Java, Python, or .NET.

Repository Protectors

Repository protectors allow you to apply data protection directly within persistent data stores, enabling sensitive data to remain protected at rest while still being used for analytics and AI workloads.

These protectors consist of Big Data Protectors for Amazon EMR, Databricks, and CDP Data Hub and Cloud-Native Data Warehouse protectors for analytics environments such as Snowflake, Redshift, and Athena.

Cloud API

The Cloud API protector extends Protegrity protection to AWS serverless and API-based workloads. It is typically used for securing transient data handled by AWS Lambda or similar function-based architectures.

3 - Infrastructure

3.1 - Preparing for Protegrity AI Team Edition

Ensure that the following prerequisites are met. If a feature is not required, skip the requirements in that section.

Infrastructure

Prerequisites for Protegrity Provisioned Cluster (PPC)

For more information, refer to Prerequisites.

Governance and Policy

Prerequisites for Protegrity Policy Manager

For more information, refer to Prerequisites.

Prerequisites for Protegrity Agent

For more information, refer to Prerequisites.

Prerequisites for Data Discovery

For more information, refer to Prerequisites.

AI Security

Prerequisites for Semantic Guardrails

For more information, refer to Prerequisites.

Data Privacy

Prerequisites for Protegrity Anonymization

For more information, refer to Prerequisites.

Prerequisites for Protegrity Synthetic Data

For more information, refer to Prerequisites.

3.2 - Configuring Authentication for Protegrity AI Team Edition

Log into My.Protegrity and obtain the necessary credentials and certificates. This portal hosts all products and features included in your Protegrity contract.

• Deploy Using PCR
• Deploy to Own Registry
• Deploy to Own Registry Using mTLS

3.3 - Protegrity Provisioned Cluster

Beyond infrastructure, Protegrity Provisioned Cluster (PPC) introduces a suite of common Protegrity Common Services (PCS), that act as the backbone for Protegrity AI Team Edition features. These include ingress control for secure traffic routing, certificate management for request validation, and robust authentication and authorization services. PPC also integrates Insight for audit logging and analytics, leveraging OpenSearch and OpenDashboards for visualization and compliance reporting. Along with this foundation, AI Team Edition delivers advanced capabilities such as policy management, anonymization, data discovery, semantic guardrails, and synthetic data generation. All these features are orchestrated within the PPC cluster. This modular approach ensures scalability, security, and flexibility, making PPC a strategic enabler for organizations adopting cloud-first and containerized environments.

3.3.1 - Installing PPC

The Protegrity Provisioned Cluster PPC is the core framework that forms the AI Team Edition. It is designed to deliver a modern, cloud-native experience for data security and governance. Built on Kubernetes, PPC uses a containerized architecture that simplifies deployment and scaling. Using OpenTofu scripts and Helm charts, administrators can stand up clusters with minimal manual intervention, ensuring consistency and reducing operational overhead.

Perform the following steps to set up and deploy the PPC:

1. Prerequisites
2. Obtaining Credentials
3. Preparing for PPC Deployment
4. Deploying PPC

3.3.1.1 - Prerequisites

Updating the Roles and Permissions using JSON

The roles and permissions are updated using the JSONs.

From the AWS Console, navigate to IAM > Policies > Create policy > JSON, and create the following JSONs.

Note: Before using the provided JSON, replace the AWS_ACCOUNT_ID and REGION values with those of the account and region where the resources are being deployed.

1. Creating KMS key and S3 bucket

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "ReadOnlyAccess",
			"Effect": "Allow",
			"Action": [
				"eks:DescribeClusterVersions",
				"ec2:DescribeInstances",
				"ec2:DescribeVolumes",
				"s3:ListAllMyBuckets",
				"iam:ListUsers",
				"ec2:RunInstances",
				"ec2:DescribeInstances",
				"ec2:DescribeVolumes",
				"ec2:CreateKeyPair",
				"ec2:DescribeImages"
			],
			"Resource": "*"
		},
		{
			"Sid": "ScopedS3AndKMS",
			"Effect": "Allow",
			"Action": [
				"s3:ListBucket",
				"s3:PutEncryptionConfiguration",
				"s3:GetEncryptionConfiguration",
				"kms:CreateKey",
				"kms:PutKeyPolicy",
				"kms:GetKeyPolicy"
			],
			"Resource": [
				"arn:aws:s3:::*",
				"arn:aws:kms:*:<AWS_ACCOUNT_ID>:key/*"
			]
		},
		{
			"Sid": "SelfServiceIAM",
			"Effect": "Allow",
			"Action": [
				"iam:ListSSHPublicKeys",
				"iam:ListServiceSpecificCredentials",
				"iam:GetLoginProfile",
				"iam:ListAccessKeys",
				"iam:CreateAccessKey"
			],
			"Resource": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/${aws:username}"
		},
        {
			"Sid": "EC2KeyPairPermission",
			"Effect": "Allow",
			"Action": [
				"ec2:CreateKeyPair",
				"ec2:DescribeKeyPairs"
			],
			"Resource": [
				"*"
			]
		}
	]
}

2. EC2 Service Policy

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "DenyEC2Instances",
			"Effect": "Deny",
			"Action": "ec2:RunInstances",
			"Resource": "arn:aws:ec2:*:*:instance/*",
			"Condition": {
				"StringLike": {
					"ec2:InstanceType": [
						"p*",
						"g*",
						"inf*",
						"trn*",
						"x*",
						"u-*",
						"z*",
						"mac*"
					]
				}
			}
		},
		{
			"Sid": "ReadOnlyDescribeListEC2RegionRestricted",
			"Effect": "Allow",
			"Action": [
				"ec2:DescribeVpcs",
				"ec2:DescribeSubnets",
				"ec2:DescribeVpcAttribute",
				"ec2:DescribeTags",
				"ec2:DescribeSecurityGroups",
				"ec2:DescribeSecurityGroupRules",
				"ec2:DescribeLaunchTemplates",
				"ec2:DescribeLaunchTemplateVersions",
				"ec2:DescribeNetworkInterfaces",
				"ec2:DescribeAccountAttributes"
			],
			"Resource": "*",
			"Condition": {
				"StringEquals": {
					"aws:RequestedRegion": [
						"<REGION>"
					]
				}
			}
		},
		{
			"Sid": "EC2LifecycleAndSecurity",
			"Effect": "Allow",
			"Action": [
				"ec2:CreateSecurityGroup",
				"ec2:DeleteSecurityGroup",
				"ec2:AuthorizeSecurityGroupIngress",
				"ec2:AuthorizeSecurityGroupEgress",
				"ec2:RevokeSecurityGroupIngress",
				"ec2:RevokeSecurityGroupEgress",
				"ec2:CreateLaunchTemplate",
				"ec2:DeleteLaunchTemplate",
				"ec2:CreateTags",
				"ec2:DeleteTags"
			],
			"Resource": [
				"arn:aws:ec2:*:*:security-group/*",
				"arn:aws:ec2:*:*:launch-template/*",
				"arn:aws:ec2:*:*:instance/*",
				"arn:aws:ec2:*:*:network-interface/*",
				"arn:aws:ec2:*:*:subnet/*",
				"arn:aws:ec2:*:*:vpc/*",
				"arn:aws:ec2:*:*:image/*",
				"arn:aws:ec2:*:*:volume/*",
				"arn:aws:ec2:*:*:snapshot/*"
			]
		}
	]
}

3. EKS Service Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ReadOnlyDescribeListEKSVersionsRegionRestricted",
            "Effect": "Allow",
            "Action": [
                "eks:DescribeAddonVersions"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": [
                        "<REGION>"
                    ]
                }
            }
        },
        {
            "Sid": "ReadOnlyDescribeListEKS",
            "Effect": "Allow",
            "Action": [
                "eks:DescribeCluster",
                "eks:DescribeAddon",
                "eks:DescribePodIdentityAssociation",
                "eks:DescribeNodegroup",
                "eks:ListAddons",
                "eks:ListPodIdentityAssociations"
            ],
            "Resource": [
                "arn:aws:eks:*:<AWS_ACCOUNT_ID>:cluster/*",
                "arn:aws:eks:*:<AWS_ACCOUNT_ID>:nodegroup/*",
                "arn:aws:eks:*:<AWS_ACCOUNT_ID>:addon/*",
                "arn:aws:eks:*:<AWS_ACCOUNT_ID>:podidentityassociation/*"
            ]
        },
        {
            "Sid": "EKSLifecycleAndTag",
            "Effect": "Allow",
            "Action": [
                "eks:CreateCluster",
                "eks:UpdateClusterVersion",
                "eks:UpdateClusterConfig",
                "eks:CreateNodegroup",
                "eks:UpdateNodegroupConfig",
                "eks:UpdateNodegroupVersion",
                "eks:DeleteNodegroup",
                "eks:CreateAddon",
                "eks:UpdateAddon",
                "eks:DeleteAddon",
                "eks:CreatePodIdentityAssociation",
                "eks:DeletePodIdentityAssociation",
                "eks:TagResource",
                "eks:ListClusters"
            ],
            "Resource": [
                "arn:aws:eks:*:<AWS_ACCOUNT_ID>:cluster/*",
                "arn:aws:eks:*:<AWS_ACCOUNT_ID>:nodegroup/*",
                "arn:aws:eks:*:<AWS_ACCOUNT_ID>:addon/*",
                "arn:aws:eks:*:<AWS_ACCOUNT_ID>:podidentityassociation/*"
            ]
        },
        {
            "Sid": "AllowEKSNodegroupSLR",
            "Effect": "Allow",
            "Action": [
                "iam:GetRole",
                "iam:CreateServiceLinkedRole"
            ],
            "Resource": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/aws-service-role/eks-nodegroup.amazonaws.com/AWSServiceRoleForAmazonEKSNodegroup"
        },
        {
            "Sid": "EKSDeleteClusterV6",
            "Effect": "Allow",
            "Action": "eks:DeleteCluster",
            "Resource": "arn:aws:eks:*:<AWS_ACCOUNT_ID>:cluster/*"
        }
    ]
}

4. IAM Service Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAdminPolicyAttachment",
            "Effect": "Deny",
            "Action": [
                "iam:AttachRolePolicy",
                "iam:PutRolePolicy"
            ],
            "Resource": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/eks-*",
            "Condition": {
                "ArnLike": {
                    "iam:PolicyARN": [
                        "arn:aws:iam::aws:policy/AdministratorAccess",
                        "arn:aws:iam::aws:policy/PowerUserAccess",
                        "arn:aws:iam::aws:policy/*FullAccess"
                    ]
                }
            }
        },
        {
            "Sid": "DenyInlinePolicyEscalation",
            "Effect": "Deny",
            "Action": [
                "iam:PutRolePolicy",
                "iam:PutUserPolicy",
                "iam:PutGroupPolicy"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ReadOnlyDescribeListIAMScoped",
            "Effect": "Allow",
            "Action": [
                "iam:GetRole",
                "iam:ListRolePolicies",
                "iam:ListAttachedRolePolicies",
                "iam:ListInstanceProfilesForRole",
                "iam:GetInstanceProfile",
                "iam:GetPolicy",
                "iam:GetPolicyVersion",
                "iam:ListPolicyVersions",
                "iam:ListAccessKeys"
            ],
            "Resource": [
                "arn:aws:iam::<AWS_ACCOUNT_ID>:role/eks-*",
                "arn:aws:iam::<AWS_ACCOUNT_ID>:instance-profile/eks-*",
                "arn:aws:iam::<AWS_ACCOUNT_ID>:policy/eks-*"
            ]
        },
        {
            "Sid": "ReadOnlyDescribeListUnavoidableStar",
            "Effect": "Allow",
            "Action": "iam:ListRoles",
            "Resource": "*"
        },
        {
            "Sid": "IAMLifecycleRolesPoliciesInstanceProfiles",
            "Effect": "Allow",
            "Action": [
                "iam:CreateRole",
                "iam:TagRole",
                "iam:CreatePolicy",
                "iam:DeletePolicy",
                "iam:DeletePolicyVersion",
                "iam:TagPolicy",
                "iam:AttachRolePolicy",
                "iam:DetachRolePolicy",
                "iam:CreateInstanceProfile",
                "iam:TagInstanceProfile",
                "iam:AddRoleToInstanceProfile",
                "iam:RemoveRoleFromInstanceProfile",
                "iam:DeleteInstanceProfile"
            ],
            "Resource": [
                "arn:aws:iam::<AWS_ACCOUNT_ID>:role/eks-*",
                "arn:aws:iam::<AWS_ACCOUNT_ID>:policy/eks-*",
                "arn:aws:iam::<AWS_ACCOUNT_ID>:instance-profile/eks-*"
            ]
        },
        {
            "Sid": "EKSDeleteRoles",
            "Effect": "Allow",
            "Action": "iam:DeleteRole",
            "Resource": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/eks*"
        },
        {
            "Sid": "PassRoleOnlyToEKS",
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/eks-*",
            "Condition": {
                "StringEquals": {
                    "iam:PassedToService": [
                        "eks.amazonaws.com",
                        "ec2.amazonaws.com",
                        "eks-pods.amazonaws.com",
                        "pods.eks.amazonaws.com"
                    ]
                }
            }
        },
        {
            "Sid": "PassRoleForEKSPodIdentityRoles",
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": [
                "arn:aws:iam::<AWS_ACCOUNT_ID>:role/eks-*-karpenter-role",
                "arn:aws:iam::<AWS_ACCOUNT_ID>:role/eks-*-backup-recovery-utility-role"
            ]
        }
    ]
}

5. KMS Service Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "KMSCreateAndList",
            "Effect": "Allow",
            "Action": [
                "kms:CreateKey",
                "kms:ListAliases"
            ],
            "Resource": "*"
        },
        {
            "Sid": "KMSKeyManagementScoped",
            "Effect": "Allow",
            "Action": [
                "kms:PutKeyPolicy",
                "kms:GetKeyPolicy",
                "kms:DescribeKey",
                "kms:GenerateDataKey",
                "kms:Decrypt",
                "kms:TagResource",
                "kms:UntagResource",
                "kms:EnableKeyRotation",
                "kms:GetKeyRotationStatus",
                "kms:ListResourceTags",
                "kms:ScheduleKeyDeletion",
                "kms:CreateAlias",
                "kms:DeleteAlias"
            ],
            "Resource": [
                "arn:aws:kms:*:<AWS_ACCOUNT_ID>:key/*",
                "arn:aws:kms:*:<AWS_ACCOUNT_ID>:alias/*"
            ]
        }
    ]
}

6. S3 Service Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3EncryptionConfigAndStateScoped",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetEncryptionConfiguration",
                "s3:PutEncryptionConfiguration",
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject",
                "s3:CreateBucket",
                "s3:GetBucketTagging",
                "s3:GetBucketPolicy",
                "s3:GetBucketAcl",
                "s3:GetBucketCORS",
                "s3:PutBucketTagging",
                "s3:GetBucketWebsite",
                "s3:GetBucketVersioning",
                "s3:GetAccelerateConfiguration",
                "s3:GetBucketRequestPayment",
                "s3:GetBucketLogging",
                "s3:GetLifecycleConfiguration",
                "s3:GetReplicationConfiguration",
                "s3:GetBucketObjectLockConfiguration",
                "s3:DeleteBucket"
            ],
            "Resource": "arn:aws:s3:::*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": [
                        "<REGION>"
                    ],
                    "aws:PrincipalAccount": "<AWS_ACCOUNT_ID>"
                }
            }
        }
    ]
}

Description for the JSON components

This section provides information for the permissions mentioned in the JSON file.

IAM Roles

Contact your IT team to create the necessary IAM roles with the following permissions to create and manage AWS EKS resources.

These policies are managed by AWS. For more information about AWS managed policies, refer to AWS managed policies for Amazon Elastic Kubernetes Service in the AWS documentation.

AWS IAM Permissions

The AWS IAM user or role to install PPC must have permissions to create and manage Amazon EKS clusters and the required supporting AWS resources.

EC2 Permissions

EKS Permissions

IAM Permissions

S3 Permissions

KMS Permissions

Jump box or local machine

A dedicated EC2 instance (RHEL 10 , Debian 12/13) for deployment.

AWS Account Details

A valid AWS account where Amazon EKS will be deployed. The AWS account ID and AWS region must be identified in advance, as all resources will be provisioned in the selected region.

Service Quotas

Verify that the AWS account has sufficient service quotas to support the deployment. At a minimum, ensure adequate limits for the following:

• EC2 instances based on node group size and instance types.
• VPC and networking limits, including subnets, route tables, and security groups.
• Elastic IP addresses and Load balancers.

If required, request quota increases through the AWS Service Quotas console before proceeding.

Service Control Policies (SCPs)

The AWS account must not have SCPs that restrict required permissions. In particular, SCPs must not block the following actions:

• eks:*
• ec2:*
• iam:PassRole

Restrictive SCPs may prevent successful cluster creation and resource provisioning.

Virtual Private Cloud (VPC)

• An existing VPC must be available in the target AWS region.
• The VPC should be configured to support Amazon EKS workloads.

Subnet Requirements

• At least two private subnets must be available.
• Subnets must be distributed across two or more Availability Zones (AZs).

Specify an AWS Region other than us-east-1

By default, the installation deploys resources in the us-east-1 AWS Region. The AWS Region is currently hardcoded in the Terraform configuration and must be manually updated to deploy to a different region.

Note: The AWS Region is defined in the iac_setup/scripts/iac/variables.tf file.

To update the AWS Region, perform the following steps:

1. Open the variables.tf file in a text editor.

2. Locate the text default = "us-east-1".

3. Replace us-east-1 with the required AWS Region. For example, "us-west-1".

4. Save the file.

Additional Step for Regions Outside North America

If you are deploying in an AWS Region outside North America, the OS image configuration must also be updated.

1. In the same variables.tf file, locate the text default = "BOTTLEROCKET_x86_64_FIPS".

2. Update the value to default = "BOTTLEROCKET_x86_64".

3. Save the file.

Creating AWS KMS Key and S3 Bucket

Amazon S3 Bucket: An Amazon S3 bucket is required to store critical data such as backups, configuration artifacts, and restore metadata used during installation and recovery workflows. Using a dedicated S3 bucket helps ensure data durability, isolation, and controlled access during cluster operations.

AWS KMS Key: An AWS KMS customer‑managed key is required to encrypt data stored in the S3 bucket. This ensures that sensitive data is protected at rest and allows customers to manage encryption policies, key rotation, and access control in accordance with their security requirements.

Note: The KMS key must allow access to the IAM roles used by the EKS cluster and related services.

The following section explains how to create AWS KMS Key and S3 Bucket. This can be done from the AWS Web UI or using the script.

• Using AWS Web UI
• Using the script

cat > kms-key-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Id": "key-resource-policy-0",
  "Statement": [
    {
      "Sid": "Allow KMS administrative actions only, no key usage permissions.",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<<ADMIN_AWS_ACCOUNT>>:root"
      },
      "Action": [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*",
        "kms:ScheduleKeyDeletion",
        "kms:CancelKeyDeletion"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow user running bootstrap.sh script of the PPC to verify the KMS key.",
      "Effect": "Allow",
      "Principal": {
        "AWS": "<<SSO_OR_IAM_USER_ACCOUNT_ARN>>"
      },
      "Action": "kms:DescribeKey",
      "Resource": "*"
    },
    {
      "Sid": "Allow backup recovery utility and EKS Node roles KMS key usage permissions, Replace <<<<CLUSTER_NAME>>>> with the name of your EKS cluster.",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<<DEPLOYMENT_AWS_ACCOUNT>>:root"
      },
      "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:ReEncryptFrom",
        "kms:ReEncryptTo",
        "kms:GenerateDataKey",
        "kms:GenerateDataKeyWithoutPlaintext",
        "kms:GenerateDataKeyPair",
        "kms:GenerateDataKeyPairWithoutPlaintext",
        "kms:DescribeKey"
      ],
      "Resource": "*",
      "Condition": {
        "ArnLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::<<DEPLOYMENT_AWS_ACCOUNT>>:role/eks-<<CLUSTER_NAME>>-backup-recovery-utility-role",
            "arn:aws:iam::<<DEPLOYMENT_AWS_ACCOUNT>>:role/eks-<<CLUSTER_NAME>>-node-role"
          ]
        }
      }
    }
  ]
}
EOF

aws sts get-caller-identity --query Arn --output text

```bash
cd <extracted_folder>/bootstrap-scripts
./init-resiliency.sh --help
```

./bootstrap-scripts/init-resiliency.sh --aws-region <AWS_region> --bucket-name <backup_bucket_name> --cluster-name <EKS_cluster_name>

   Do you want to proceed with creating the S3 bucket and KMS key? (yes/no) : 

3.3.1.2 - Preparing for PPC deployment

This section describes the steps to download and extract the recipe for deploying the PPC.

Note: If you have set up the jump box previously, then from /deployment/iac_setup/ directory, run the make clean command. This ensures that the local repository on the jump box and the clusters are cleaned up before proceeding with a new installation.

Warning: Do not install or manage multiple clusters from the same working directory. Each cluster deployment maintains its own Terraform/OpenTofu state, and reusing a directory can overwrite state files, causing loss of cluster tracking and unintended cleanup behavior.
Use a dedicated directory, and jump box, where possible, per cluster, and always verify the active kubectl context before running cleanup commands such as make clean.

1. Log in to the My.Protegrity portal.

2. Navigate to Product Management > Explore Products > AI Team Edition.

3. From the Release list, select a release version.

4. From Platform and Feature Installation, click the Download Product icon.

5. Create a deployment directory on the jumpbox.

   mkdir deployment && cd deployment
   

6. Copy the archive to the deployment directory on the jumpbox.

7. Extract the archive.

   tar -xvf PPC-K8S-64_x86-64_AWS-EKS_1.0.0.x
   

3.3.1.3 - Deploying PPC

Before you begin

• Before running the bootstrap or resiliency scripts as the root user on RHEL, ensure that /usr/local/bin (and the AWS CLI binary path, if applicable) is included in the $PATH. Alternatively, run the script using a non-root user (such as ec2-user) where /usr/local/bin is already part of the default PATH.

• By default, the installation is configured to use the us-east-1 AWS region. If you plan to install the product in a different region, update the region value in the iac_setup/scripts/iac/variables.tf file before starting the installation.

  For more information on updating the AWS region, refer to Specify an AWS Region other than us-east-1.

The repository provides a bootstrap script that automatically installs or updates the following software on the jump box:

• AWS CLI - Required to communicate with your AWS account.
• OpenTofu - Required to manage infrastructure as code.
• kubectl - Required to communicate with the Kubernetes cluster.
• Helm - Required to manage Kubernetes packages.
• Make - Required to run the OpenTofu automation scripts.
• jq - Required to parse JSON.

The bootstrap script also checks if you have the required permissions on AWS. It then sets up the EKS cluster and installs the microservices required for deploying the PPC.

The bootstrap script asks for variables to be set to complete your deployment. Follow the instructions on the screen:

./bootstrap.sh

The script prompts for the following variables.

1. Enter Cluster Name

   The following characters are allowed:

   • Lowercase letters: a-z
   • Numbers: 0-9
   • Hyphens: -

   The following characters are not allowed:

   • Uppercase letters: A-Z
   • Underscores: _
   • Spaces
   • Any special characters such as: / ? * + % ! @ # $ ^ & ( ) = [ ] { } : ; , .
   • Leading or trailing hyphens
   • More than 31 characters

   Note: Ensure that the cluster name does not exceed 31 characters. Cluster names longer than this limit can cause the bootstrap script to fail in subsequent installation steps.
   If the installation fails because the cluster name exceeds the 31-character limit, correct the name and re-run the script.
   

   • Correction: Choose a cluster name with 31 characters or fewer.
     
   • Retry: Execute the installation command again with the updated name. The script will automatically handle the update and proceed with the bootstrap process.

2. Enter a VPC ID from the table

   The script automatically retrieves the available VPCs. Enter the VPC ID where the cluster must be created.

3. Querying for subnets in VPC…

   The script queries for the available VPC subnets and prompts to enter two private subnet IDs. Specify two private subnet IDs from different availability zones.
   The script then automatically updates the VPC CIDR block based on the VPC details.

4. Enter FQDN

   This is the Fully Qualified Domain Name for the ingress.

   Warning: Ensure that the FQDN does not exceed 50 characters and only the following characters are used:

   • Lowercase letters: a-z
   • Numbers: 0-9
   • Special characters: - .

5. Enter S3 Backup Bucket Name

   An AWS S3 bucket encrypted with SSE‑KMS for storing backup data for disaster recovery.

   Use a dedicated S3 bucket per cluster for backup and restore operations to ensure data and encryption isolation. Sharing a bucket across clusters increases the risk of cross-cluster data access or decryption due to IAM misconfiguration. Dedicated buckets with unique IAM policies eliminate this risk.

   During disaster management, OpenSearch restores only those snapshots that are created using the daily-insight-snapshots policy. For more information, refer to Backing up and restoring indexes.

6. Enter Image Registry Endpoint

   The image repository from where the container images are retrieved. Use registry.protegrity.com:9443 for using the Protegrity Container Registry (PCR), else use the local repository endpoint for the local repository.

   Expected format: [:port]. Do not include ‘https://’

   Note: The container registry endpoint must be a FQDN (Fully Qualified Domain Name). Sub-paths like, my-registry.com/v2/path, are not supported by the OCI distribution specification.

7. Enter Registry Username []

   Enter the username for the registry mentioned in the previous step. Leave this entry blank if the registry does not require authentication.

8. Enter Registry Password or Access Token

   Enter Password or Access Token for the registry. Input is masked with * characters. Press Enter to keep the current value. Leave this entry blank if the registry does not require authentication.

9. After providing all information, the following confirmation message appears.

Configuration updated successfully.

Would you like to proceed with the setup now?

Proceed? (yes/no): 

Type yes to initiate the setup.

Note: The cluster creation process can take 10-15 minutes.

If the session is terminated during installation due to network issues, power outage, and so on, then the installation stops. To restart the installation, run the following commands:

# Navigate to setup directory 
cd iac_setup

# Clean up all resources
make clean

# Navigate to setup directory 
./boostrap.sh

Warning: Do not install or manage multiple clusters from the same working directory. Each cluster deployment maintains its own Terraform/OpenTofu state, and reusing a directory can overwrite state files, causing loss of cluster tracking and unintended cleanup behavior.
Use a dedicated directory, and jump box, where possible, per cluster, and always verify the active kubectl context before running cleanup commands such as make clean.
To check the active kubectl context, run the following command:
kubectl config current-context

3.3.2 - Accessing PPC using a Linux machine

Before you begin

Ensure that the following prerequisites are met.

• A Linux machine is available and running.
• AWS CLI is installed and configured.
• Kubernetes command-line tool is installed.

Perform the following steps to access PPC using a separate Linux machine.

1. Log in to Linux machine with root credentials.

2. Configure AWS credentials, using the following command.

   aws configure
   

3. Verify that AWS credentials are working, using the following command.

   aws sts get-caller-identity
   

4. If the Kubernetes command-line tool is not available, then install the Kubernetes command-line tool, using the following command.

   kubectl version --client 2>/dev/null || {
    echo "Installing kubectl..."
    curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
    chmod +x kubectl
    sudo mv kubectl /usr/local/bin/
    kubectl version --client
   }
   

5. Set up the Kubernetes command-line tool and access the cluster, using the following command.

   aws eks update-kubeconfig --region <region_name> --name <cluster_name>
   

6. Verify the access to the cluster, using the following command.

   kubectl get nodes
   

3.3.3 - Installing Features and Protectors

Before you begin

Ensure that PPC is successfully installed before installing the features or protectors.

Installing Features

The following table lists the available features.

Installing Protectors

The following table lists the available protectors.

3.3.4 - Login to PPC

3.3.4.1 - Prerequisites

Use Route 53 configuration on AWS to resolve the PPC FQDN specified during the installation to the internal load balancer.

• Ensure that the instance is using the AWS-provided DNS server, such as, VPC CIDR + 2.
• Verify that enableDnsHostnames and enableDnsSupport are set to true in the VPC settings.
• Verify the Security Group of the load balancer. Ensure that Inbound traffic is allowed on the required ports, such as, 80 and 443, from the client instance’s IP or Security Group.
• Keep the following information ready:
  • VPC ID: The ID of the VPC for the client instances and the Load Balancer. For example, vpc-0123456789.
  • Internal ELB DNS Name: The DNS name of the load balancer. For example, internal-abcdefghi123456-123456789.us-east-1.amazonaws.com.
  • Target FQDN: The FQDN for PPC. For example, mysite.aws.com.

1. Find the AWS Load Balancer address.

   kubectl get gateway -A
   

   The output appears similar to the following:

   NAMESPACE     NAME       CLASS   ADDRESS                                                                           PROGRAMMED   AGE
   api-gateway   pty-main   envoy   internal-abcdefghi123456-123456789.us-east-1.elb.amazonaws.com   True 
   

2. Map the PPC FQDN to the load balancer using Route 53.

For more information about configuring Route 53, refer to the AWS documentation.

3.3.4.2 - Log in to PPC

Access the PPC using the FQDN provided during the installation process.

Enter the username and password for the admin user to log in and view the Insight Dashboard.

If Protegrity Agent is installed, then the Protegrity Agent dashboard appears. Click Insight to open the Insight Dashboard. For more information about Protegrity Agent, refer to Using Protegrity Agent.

3.3.5 - Accessing the PPC CLI

3.3.5.1 - Prerequisites

To access the PPC CLI, ensure that the following prerequisites are met.

• SSH Keys: The SSH private key that corresponds to the public key configured in the pty-cli pod is required.

• Network Access: Ensure to have network connectivity to the cluster.

• Resolve FQDN: Use Route 53 configuration on AWS to resolve the PPC FQDN specified during the installation to the internal load balancer. For more information, refer to Prerequisites.

For Linux/macOS Users

The private key to access the CLI pod will be in the /deployment/keys directory. The key file is authorized_keys.

From the /deployment/keys directory:

ssh -i authorized_keys -p 22 ptyitusr@<user-provided-fqdn>

With options to skip host key checking:

ssh -i authorized_keys -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -p 22 ptyitusr@<user-provided-fqdn>

For Windows Users

The private key to access the CLI pod will be in the /deployment/keys directory. The key file is authorized_keys. Copy the key file to a directory on the local Windows machine.

1. Using Windows SSH Client (Windows 10/11 with OpenSSH):

   ssh -i C:\path\to\copied\file\authorized_keys -p 22 ptyitusr@<user-provided-fqdn>
   

2. Using PuTTY:

   • Host Name: <user-provided-fqdn>
   • Port: 22
   • Connection Type: SSH
   • Under Connection > SSH > Auth, browse and select your private key file (.ppk format)
   • Username: ptyitusr

3.3.5.2 - Accessing the PPC CLI

Once connected, the Protegrity CLI welcome banner displays. Enter the following parameters when prompted:

• Username: Application username
• Password: Application password

For more information about the default credentials, refer to the Release Notes.

The CLI supports two main command categories:

• pim: Policy Information Management commands for data protection policies
• admin: User, Role, Permission, and Group management commands

Note: Ensure that at least one additional backup administrator user is configured with the same administrative privileges as the primary admin user.
If the primary admin account is locked or its credentials are lost, restoring the system from a backup may be the only recovery option.

3.3.6 - Deleting PPC

Uninstalling Features and Protectors

To uninstall features and protectors, refer the relevant documentation.

Cleaning up the EKS Resources

To destroy all created resources, including the EKS cluster and related components, run the following commands.

# Navigate setup directory
cd iac_setup

# Clean up all resources
make clean

Executing this command destroys the PPC and all related components.

3.3.7 - Restoring the PPC

Before you begin

Before starting a restore, ensure the following conditions are met:

• An existing backup is available. Backups are taken automatically as part of the default installation using scheduled backup mechanisms. These backups are stored in an AWS S3 bucket configured during the original installation.

• Access to the original backup AWS S3 bucket. During restore, the same S3 bucket that was used during the original installation must be specified.

• Before initiating the restore, review and update the KMS key policy to reflect the restore cluster name. Even if the policy was already configured for the source cluster, it must be updated for the new restore cluster. If the policy continues to reference the source cluster name, the IAM role created during restore cannot decrypt the backup data, causing the restore to fail.

• Permissions to read from the S3 bucket. The user performing the restore must have sufficient permissions to access the backup data stored in the bucket.

• A new Kubernetes cluster is created. Restore is performed as part of creating a new cluster, not on an existing one. Restore is only supported during a fresh installation flow.

• While the backup is taken from the source cluster, do not perform Create, Read, Update, or Delete (CRUD) operations on the source cluster. This ensures backup consistency and prevents data corruption during restore.

• Before restoring to a new cluster, if the source cluster is accessible, disable the backup operations on the source cluster by setting the backup storage location to read‑only. This ensures that no additional backup data is written during the restore process.

  To disable the backup operation on the source cluster, run the following command:

  kubectl patch backupstoragelocation default -n pty-backup-recovery --type merge -p '{"spec":{"accessMode":"ReadOnly"}}'
  

  If the source cluster is not accessible, this step can be skipped.

During Disaster management, the backup data is used to restore the cluster and the OpenSearch indexes using snapshots. However, Insight restores OpenSearch data only from the most recent snapshot created by the daily-insight-snapshots policy.
For more information, refer to Backing up and restoring indexes.

Warning: Do not install or manage multiple clusters from the same working directory. Each cluster deployment maintains its own Terraform/OpenTofu state, and reusing a directory can overwrite state files, causing loss of cluster tracking and unintended cleanup behavior.
Use a dedicated directory, and jump box, where possible, per cluster, and always verify the active kubectl context before running cleanup commands such as make clean.

The repository provides a bootstrap script that automatically installs or updates the following software on the jump box:

• AWS CLI - Required to communicate with your AWS account.
• OpenTofu - Required to manage infrastructure as code.
• kubectl - Required to communicate with the Kubernetes cluster.
• Helm - Required to manage Kubernetes packages.
• Make - Required to run the OpenTofu automation scripts.
• jq - Required to parse JSON.

The bootstrap script also checks if you have the required permissions on AWS. It then sets up the EKS cluster and installs the microservices required for deploying the PCS on a PPC.

Note: Before running the bootstrap or resiliency scripts as the root user on RHEL, ensure that /usr/local/bin (and the AWS CLI binary path, if applicable) is included in the $PATH. Alternatively, run the script using a non-root user (such as ec2-user) where /usr/local/bin is already part of the default PATH.

Run the following command to initiate restore using an existing backup:

./bootstrap.sh --restore

The bootstrap script asks for variables to be set to complete the deployment. Follow the instructions on the screen.

The --restore command enables the restore mode for the installation. It initiates restoration of data from the configured backup bucket. This process must be followed on a fresh installation.

The script prompts for the following variables.

1. Enter Cluster Name

   • Ensure that the cluster name does not match the name of the source cluster. Reusing an existing cluster name during restore can lead to discrepancies during cluster installation.
     
   • This same cluster name must already be updated in the KMS key policy. If this update is not performed, the restore process fails because the new cluster cannot decrypt the backup data.
     
   • Ensure that the cluster name does not exceed 31 characters. Cluster names longer than this limit can cause the bootstrap script to fail in subsequent installation steps.
     If the installation fails because the cluster name exceeds the 31-character limit, correct the name and re-run the script.
     
     • Correction: Choose a cluster name with 31 characters or fewer.
       
     • Retry: Execute the installation command again with the updated name. The script will automatically handle the update and proceed with the bootstrap process.

   The following characters are allowed:

   • Lowercase letters: a-z
   • Numbers: 0-9
   • Hyphens: -

   The following characters are not allowed:

   • Uppercase letters: A-Z
   • Underscores: _
   • Spaces
   • Any special characters such as: / ? * + % ! @ # $ ^ & ( ) = [ ] { } : ; , .
   • Leading or trailing hyphens
   • More than 31 characters

2. Enter a VPC ID from the table

   The script automatically retrieves the available VPCs. Enter the VPC ID where the cluster must be created.

3. Querying for subnets in VPC

   The script automatically queries for the available VPC subnets and prompts to enter two private subnet IDs. Specify two private subnet IDs from different availability zones.
   The script then automatically updates the VPC CIDR block based on the VPC details.

4. Enter FQDN

   This is the Fully Qualified Domain Name for the ingress.

   Ensure only the following characters are used:

   • Lowercase letters: a-z
   • Numbers: 0-9
   • Special characters: - .

5. Enter S3 Backup Bucket Name

   An AWS S3 bucket encrypted with SSE‑KMS containing backup artifacts used during the restore process.

   Use a dedicated S3 bucket per cluster for backup and restore operations to ensure data and encryption isolation. Sharing a bucket across clusters increases the risk of cross-cluster data access or decryption due to IAM misconfiguration. Dedicated buckets with unique IAM policies eliminate this risk.

6. Enter Image Registry Endpoint

   The image repository from where the container images are retrieved.

   Expected format: [:port]. Do not include ‘https://’

   Note: The container registry endpoint must be a FQDN (Fully Qualified Domain Name). Sub-paths like, my-registry.com/v2/path, are not supported by the OCI distribution specification.

7. Enter Registry Username

   Enter the username for the registry mentioned in the previous step. Leave this entry blank if the registry does not require authentication.

8. Enter Registry Password or Access Token

   Enter Password or Access Token for the registry. Input is masked with * characters. Press Enter to keep the current value.

   Leave this entry blank if the registry does not require authentication.

9. After providing all information, the following confirmation message appears.

   Configuration updated successfully.
   
   Would you like to proceed with the setup now?
   
   Proceed? (yes/no): 
   

   Type yes to initiate the setup.

Restore from latest backup? [Y/n]

• Enter Y to restore from the most recent backup.
• Enter n to manually select a backup.

If you choose to manually select a backup, then the script displays a list of available backups (latest first) and prompts to select one by number:

Available backups (latest first):
  [1] authnz-postgresql-schedule-backup-<timestamp>
  [2] authnz-postgresql-schedule-backup-<timestamp>

Select a backup number:

After entering the backup number, the chosen backup is used for the restore, and the installation continues.

Note: The cluster creation process can take 10-15 minutes.

If the session is terminated during restore due to network issues, power outage, and so on, then the restore stops. To restart the process, run the following commands:

# Navigate to setup directory
cd iac_setup

# Clean up all resources
make clean

./boostrap.sh --restore

Warning: Do not install or manage multiple clusters from the same working directory. Each cluster deployment maintains its own Terraform/OpenTofu state, and reusing a directory can overwrite state files, causing loss of cluster tracking and unintended cleanup behavior.
Use a dedicated directory, and jump box, where possible, per cluster, and always verify the active kubectl context before running cleanup commands such as make clean.
To check the active kubectl context, run the following command:
kubectl config current-context

After the restore to the new cluster is completed successfully and all required validation and migration activities are finished, the source cluster can be deleted.

3.4 - Working with Insight

Insight is a comprehensive system designed to store and manage logs in the Audit Store, which is a repository for all audit data and logs. The Audit Store cluster is scalable and supports multiple nodes. Insight provides various functionalities, including accessing dashboards, viewing logs, and creating visualizations. It also offers tools for analyzing data, monitoring system health, and ensuring secure communication between components.

3.4.1 - Overview of the dashboards

Viewing the graphs provides an easier and faster method for reading the log information. This helps understand the working of the system and also take decisions faster, such as, understanding the processing load on the cluster and accordingly expanding the cluster by adding nodes, if required.

For more information about the dashboards, refer to OpenSearch Dashboards.

Accessing the Insight Dashboard

The Insight Dashboard appears after logging in. Complete the steps provided here to view the Insight Dashboard.

1. Complete the steps from Login to PPC.

2. Navigate to the PPC FQDN using a web browser.

3. Log in with the username and password.

   The Insight Dashboard is displayed.

   Note: If the Protegrity Agent is installed, then the Protegrity Agent dashboard is displayed. Click Insight to open the Insight Dashboard. For more information about the Protegrity Agent, refer to Using Protegrity Agent.

The data and time are displayed using the UTC format. To update the format, from the Menu, click Dashboards Management > Advanced settings, locate dateFormat:tz (Timezone for date formatting), click Edit, select the required format, and click Save. The appropriate format helps to set the time for scheduled tasks.

Accessing the help

The Insight Dashboard helps visualize log data and information. Use the help documentation provided by Insight to configure and create visualizations.

To access the help:

1. Open the Insight Dashboard.

2. Click the Help icon from the upper-right corner of the screen.

3. Click Documentation.

   Alternatively, refer to OpenSearch Dashboards.

3.4.2 - Working with Discover

For more information about Discover, refer to OpenSearch Dashboards.

Viewing logs

The logs aggregated and collected are sent to Insight. Insight stores the logs in the Audit Store. The logs from the Audit Store are displayed on the Insight Dashboard. Here, the different fields and the data logged is visible. In addition to viewing the data, these logs serve as input for Analytics to analyze the health of the system and to monitor the system for providing security.

View the logs by logging into the system and from the menu, select Discover, and select a time period such as Last 30 days.

Use the default index pty_insight_analytics*audits_* to view the log data. This default index pattern uses wildcard charaters for referencing all indexes. Alternatively, select an index pattern or alias for the entries to view the data from a different index.

After an index is deleted, the data associated with it is permanently removed, and without a backup, there is no way to recover it. For more information about indexes, refer to Managing indexes and OpenSearch Dashboards. For more information about managing Audit Store indexes, refer to Index state management (ISM).

Saved queries

Run a query and customize the log details displayed. Save the query and the settings for running a query, such as, the columns, row count, tail, and indexes for the query. The saved queries created are user-specific.

From Discover, click Open to use the following saved queries to view information:

• Policy search: This query is available to view policy logs. A policy log is a created during the the policy creation, policy deployment, policy enforcement, and during the collection, storage, forwarding, and analysis of logs.
• Security search: This query is available to view security operation logs. A security log is created during various security operations performed by protectors, such as, performing protect, unprotect, and reprotect operations.
• Signature Verification Search: This query is available to view signature verification information.
• Unsuccessful Security Operations: This query is available to view unsuccessful security operation-related logs. Unsuccessful Security Operations logs are created when security operations fail due to errors, warnings, or exceptions.

1. Log in to the Insight Dashboard using a web browser.

2. Select Discover from the menu, and optionally select a time period such as Last 30 days..

3. Select the index for running the query.

4. Enter the query in the Search field.

5. Optionally, select the required fields.

6. Click the See saved queries icon to save the query.

   The Saved Queries list appears.

7. Click Save current query.

   The Save query dialog box appears.

8. Specify a name for the query.

9. Click Save to save the query information, including the configurations specified, such as, the columns, row count, tail, indexes, and query.

   The query is saved.

10. Click the See saved queries icon to view the saved queries.

3.4.2.1 - Understanding the Insight indexes

All the features and Protectors send logs to Insight. The logs from the Audit Store are displayed on the Discover screen of the Insight Dashboard. Here, you can view the different fields logged. In addition to viewing the data, these logs serve as input for Insight to analyze the health of the system and to monitor the system for providing security. These logs are stored in the Audit index with the name, such as, pty_insight_analytics_audits_1.0*.

You can view the Discover screen by logging into the Insight Dashboard, selecting Discover from the menu, and selecting a time period such as Last 30 days.

The following table lists the various indexes and information about the data contained in the index. You can view the index list for PPC, by logging into the Insight Dashboard, and navigating to Index Management > State management policies. To view all the indexes, select Indexes. Indexes can be created or deleted. However, deleting an index will lead to a permanent loss of data in the index. If the index was not backed up earlier, then the logs from the index deleted cannot be recreated or retrieved.

3.4.2.2 - Understanding the index field values

Common Logging Information

These logging fields are common with the different log types generated by Protegrity products.

Note: These common fields are used across all log types.

Additional_Info

These descriptions are used for all types of logs.

Process

This section describes the properties of the process that created the log. For example, the protector or the rputils.

Origin

This section describes the origin of the log, that is, from where the log came from and when it was generated.

Protector

This section describes the Protector that generated the log. For example, the vendor and the version of the Protector.

Note: For more information about the Protector vendor, family, and version, refer here.

Protection

This section describes the protection that was done, what was done, the result of the operation, where it was done, and so on.

Client

This section describes from where the log came from.

Policy

This section describes the information about the policy.

Signature

This section handles the signing of the log. The key that was used to sign the log and the actual checksum that was generated.

Verification

This section describes the log information generated for a failed signature verification job.

3.4.2.3 - Index entries

Audit index

The log types of protection, metering, audit, and security are stored in the audit index. These log are generated during security operations. The logs generated by protectors are stored in the pty_insight_analytics_*audits* audit index.

Protection logs

These logs are generated by protectors during protecting, unprotecting, and reprotecting data operations. These logs are generated by protectors.

Use the following query in Discover to view these logs.

logtype:protection

A sample log is shown here:

 {
    "process": {
      "thread_id": "1227749696",
      "module": "coreprovider",
      "name": "java",
      "pcc_version": "3.6.0.1",
      "id": "4190",
      "user": "user4",
      "version": "10.0.0-alpha+13.gef09.10.0",
      "core_version": "2.1.0+17.gca723.2.1",
      "platform": "Linux_x64"
    },
    "level": "SUCCESS",
    "signature": {
      "key_id": "11a8b7d9-1621-4711-ace7-7d71e8adaf7c",
      "checksum": "43B6A4684810383C9EC1C01FF2C5CED570863A7DE609AE5A78C729A2EF7AB93A"
    },
    "origin": {
      "time_utc": "2024-09-02T13:55:17.000Z",
      "hostname": "hostname1234",
      "ip": "10.39.3.156"
    },
    "cnt": 1,
    "protector": {
      "vendor": "Java",
      "pcc_version": "3.6.0.1",
      "family": "sdk",
      "version": "10.0.0-alpha+13.gef09.10.0",
      "core_version": "2.1.0+17.gca723.2.1"
    },
    "protection": {
      "dataelement": "TE_A_S13_L1R2_Y",
      "datastore": "DataStore",
      "audit_code": 6,
      "operation": "Protect",
      "policy_user": "user1"
    },
    "index_node": "protegrity-ppc399/10.39.1.23",
    "tiebreaker": 210,
    "logtype": "Protection",
    "additional_info": {
      "description": "Data protect operation was successful"
    },
    "index_time_utc": "2024-09-02T13:55:24.766355224Z",
    "ingest_time_utc": "2024-09-02T13:55:17.678Z",
    "client": {},
    "correlationid": "cm0f1jlq700gbzb19cq65miqt"
  },
  "fields": {
    "origin.time_utc": [
      "2024-09-02T13:55:17.000Z"
    ],
    "index_time_utc": [
      "2024-09-02T13:55:24.766Z"
    ],
    "ingest_time_utc": [
      "2024-09-02T13:55:17.678Z"
    ]
  },
  "sort": [
    1725285317000
  ]

The above example contains the following information:

• additional_info
• origin
• protector
• protection
• process
• client
• protector
• signature

For more information about the various fields, refer here.

Metering logs

These logs are generated by protectors of prior to 8.0.0.0. These logs are not generated by latest protectors.

Use the following query in Discover to view these logs.

logtype:metering

For more information about the various fields, refer here.

Audit logs

These logs are generated when the rule set of the protector gets updated.

Use the following query in Discover to view these logs.

logtype:audit

A sample log is shown here:

 {
   "additional_info.description": "User admin modified default_80 tunnel successfully ",
   "additional_info.title": "Gateway : Tunnels : Tunnel 'default_80' Modified",
   "client.ip": "192.168.2.20",
   "cnt": 1,
   "index_node": "protegrity-ppc746/192.168.1.10",
   "index_time_utc": "2024-01-24T13:30:17.171646Z",
   "ingest_time_utc": "2024-01-24T13:29:35.000000000Z",
   "level": "Normal",
   "logtype": "Audit",
   "origin.hostname": "protegrity-cg406",
   "origin.ip": "192.168.2.20",
   "origin.time_utc": "2024-01-24T13:29:35.000Z",
   "process.name": "CGP",
   "process.user": "admin",
   "tiebreaker": 2260067,
   "_id": "ZTdhNzFmMTUtMWZlOC00MmY4LWJmYTItMjcwZjMwMmY4OGZh",
   "_index": "pty_insight_audit_v9.1-2024.01.23-000006"
 }

This example includes data from each of the following groups defined in the index:

• additional_info
• client
• origin
• process

For more information about the various fields, refer here.

Security logs

These logs are generated by security events of the system.

Use the following query in Discover to view these logs.

logtype:security

For more information about the various fields, refer here.

Troubleshooting index

The log types of application, kernel, system, and verification logs are stored in the troubleshooting index. These logs helps you understand the working of the system. The logs stored in this index are essential when the system is down or has issues. This is the pty_insight_analytics_troubleshooting index. The index pattern for viewing these logs in Discover is pty_insight_analytics_*troubleshooting_*.

Application Logs

These logs are generated by Protegrity servers and Protegrity applications.

Use the following query in Discover to view these logs.

logtype:application

A sample log is shown here:

{
    "process": {
      "name": "hubcontroller"
    },
    "level": "INFO",
    "origin": {
      "time_utc": "2024-09-03T10:02:34.597000000Z",
      "hostname": "protegrity-ppc503",
      "ip": "10.37.4.12"
    },
    "cnt": 1,
    "index_node": "protegrity-ppc503/10.37.4.12",
    "tiebreaker": 16916,
    "logtype": "Application",
    "additional_info": {
      "description": "GET /dps/v1/deployment/datastores | 304 | 127.0.0.1 | Protegrity Client | 8ms | "
    },
    "index_time_utc": "2024-09-03T10:02:37.314521452Z",
    "ingest_time_utc": "2024-09-03T10:02:36.262628342Z",
    "correlationid": "cm0m9gjq500ig1h03zwdv6kok"
  },
  "fields": {
    "origin.time_utc": [
      "2024-09-03T10:02:34.597Z"
    ],
    "index_time_utc": [
      "2024-09-03T10:02:37.314Z"
    ],
    "ingest_time_utc": [
      "2024-09-03T10:02:36.262Z"
    ]
  },
  "highlight": {
    "logtype": [
      "@opensearch-dashboards-highlighted-field@Application@/opensearch-dashboards-highlighted-field@"
    ]
  },
  "sort": [
    1725357754597
  ]

The above example contains the following information:

• additional_info
• origin
• process

For more information about the various fields, refer here.

Kernel logs

These logs are generated by the kernel and help you analyze the working of the internal system. Some of the modules that generate these logs are CRED_DISP, KERNEL, USER_CMD, and so on.

Use the following query in Discover to view these logs.

logtype:Kernel

For more information and description about the components that can generate kernel logs, refer here.

For a list of components and modules and the type of logs they generate, refer here.

A sample log is shown here:

{
    "process": {
      "name": "CRED_DISP"
    },
    "origin": {
      "time_utc": "2024-09-03T10:02:55.059999942Z",
      "hostname": "protegrity-ppc503",
      "ip": "10.37.4.12"
    },
    "cnt": "1",
    "index_node": "protegrity-ppc503/10.37.4.12",
    "tiebreaker": 16964,
    "logtype": "Kernel",
    "additional_info": {
      "module": "pid=38236",
      "description": "auid=4294967295 ses=4294967295 subj=unconfined msg='op=PAM:setcred grantors=pam_rootok acct=\"rabbitmq\" exe=\"/usr/sbin/runuser\" hostname=? addr=? terminal=? res=success'\u001dUID=\"root\" AUID=\"unset\"",
      "procedure": "uid=0"
    },
    "index_time_utc": "2024-09-03T10:02:59.315734771Z",
    "ingest_time_utc": "2024-09-03T10:02:55.062254541Z"
  },
  "fields": {
    "origin.time_utc": [
      "2024-09-03T10:02:55.059Z"
    ],
    "index_time_utc": [
      "2024-09-03T10:02:59.315Z"
    ],
    "ingest_time_utc": [
      "2024-09-03T10:02:55.062Z"
    ]
  },
  "highlight": {
    "logtype": [
      "@opensearch-dashboards-highlighted-field@Kernel@/opensearch-dashboards-highlighted-field@"
    ]
  },
  "sort": [
    1725357775059
  ]

This example includes data from each of the following groups defined in the index:

• additional_info
• origin
• process

For more information about the various fields, refer here.

System logs

These logs are generated by the operating system and help you analyze and troubleshoot the system when errors are found.

Use the following query in Discover to view these logs.

logtype:System

For a list of components and modules and the type of logs they generate, refer here.

A sample log is shown here:

 {
    "process": {
      "name": "PPCPAP",
      "version": "10.0.0+2412",
      "user": "admin"
    },
    "level": "Low",
    "origin": {
      "time_utc": "2024-09-03T10:00:34.000Z",
      "hostname": "protegrity-ppc503",
      "ip": "10.37.4.12"
    },
    "cnt": "1",
    "index_node": "protegrity-ppc503/10.37.4.12",
    "tiebreaker": 16860,
    "logtype": "System",
    "additional_info": {
      "description": "License is due to expire in 30 days. The validity of license has been acknowledged by the user. (web-user 'admin' , IP: '10.87.2.32')",
      "title": "Appliance Info : License is due to expire in 30 days. The validity of license has been acknowledged by the user. (web-user 'admin' , IP: '10.87.2.32')"
    },
    "index_time_utc": "2024-09-03T10:01:10.113708469Z",
    "client": {
      "ip": "10.37.4.12"
    },
    "ingest_time_utc": "2024-09-03T10:00:34.000000000Z"
  },
  "fields": {
    "origin.time_utc": [
      "2024-09-03T10:00:34.000Z"
    ],
    "index_time_utc": [
      "2024-09-03T10:01:10.113Z"
    ],
    "ingest_time_utc": [
      "2024-09-03T10:00:34.000Z"
    ]
  },
  "highlight": {
    "logtype": [
      "@opensearch-dashboards-highlighted-field@System@/opensearch-dashboards-highlighted-field@"
    ]
  },
  "sort": [
    1725357634000
  ]

This example includes data from each of the following groups defined in the index:

• additional_info
• origin
• process

For more information about the various fields, refer here.

Verification logs

These log are generated by Insight on when a signature verification fails.

Use the following query in Discover to view these logs.

logtype:Verification

For a list of components and modules and the type of logs they generate, refer here.

A sample log is shown here:

{
    "process": {
      "name": "insight.pyc",
      "id": 45277
    },
    "level": "Info",
    "origin": {
      "time_utc": "2024-09-03T10:14:03.120342Z",
      "hostname": "protegrity-ppc503",
      "ip": "10.37.4.12"
    },
    "cnt": 1,
    "index_node": "protegrity-ppc503/10.37.4.12",
    "tiebreaker": 17774,
    "logtype": "Verification",
    "additional_info": {
      "module": ".signature.job_executor",
      "description": "",
      "procedure": "__log_failure"
    },
    "index_time_utc": "2024-09-03T10:14:03.128435514Z",
    "ingest_time_utc": "2024-09-03T10:14:03.120376Z",
    "verification": {
      "reason": "SV_VERIFY_RESPONSES.INVALID_CHECKSUM",
      "job_name": "System Job",
      "job_id": "9Vq1opEBYpV14mHXU9hW",
      "index_name": "pty_insight_analytics_audits_10.0-2024.08.30-000001",
      "doc_id": "JI5bt5EBMqY4Eog-YY7C"
    }
  },
  "fields": {
    "origin.time_utc": [
      "2024-09-03T10:14:03.120Z"
    ],
    "index_time_utc": [
      "2024-09-03T10:14:03.128Z"
    ],
    "ingest_time_utc": [
      "2024-09-03T10:14:03.120Z"
    ]
  },
  "highlight": {
    "logtype": [
      "@opensearch-dashboards-highlighted-field@Verification@/opensearch-dashboards-highlighted-field@"
    ]
  },
  "sort": [
    1725358443120
  ]

This example includes data from each of the following groups defined in the index:

• additional_info
• process
• origin
• verification

For more information about the various fields, refer here.

Policy log index

The log type of policy is stored in the policy log index. They include logs for the policy-related operations, such as, when the policy is updated. The index pattern for viewing these logs in Discover is pty_insight_analytics_*policy_log_*.

Use the following query in Discover to view these logs.

logtype:policyLog

For a list of components and modules and the type of logs they generate, refer here.

A sample log is shown here:

{
    "process": {
      "name": "hubcontroller",
      "user": "service_admin",
      "version": "1.8.0+6.g5e62d8.1.8"
    },
    "level": "Low",
    "origin": {
      "time_utc": "2024-09-03T08:29:14.000000000Z",
      "hostname": "protegrity-ppc503",
      "ip": "10.37.4.12"
    },
    "cnt": 1,
    "index_node": "protegrity-ppc503/10.37.4.12",
    "tiebreaker": 10703,
    "logtype": "Policy",
    "additional_info": {
      "description": "Data element created. (Data Element 'TE_LASCII_L2R1_Y' created)"
    },
    "index_time_utc": "2024-09-03T08:30:31.358367506Z",
    "client": {
      "ip": "10.87.2.32",
      "username": "admin"
    },
    "ingest_time_utc": "2024-09-03T08:29:30.017906235Z",
    "correlationid": "cm0m64iap009r1h0399ey6rl8",
    "policy": {
      "severity": "Low",
      "audit_code": 150
    }
  },
  "fields": {
    "origin.time_utc": [
      "2024-09-03T08:29:14.000Z"
    ],
    "index_time_utc": [
      "2024-09-03T08:30:31.358Z"
    ],
    "ingest_time_utc": [
      "2024-09-03T08:29:30.017Z"
    ]
  },
  "highlight": {
    "additional_info.description": [
      "(Data Element '@opensearch-dashboards-highlighted-field@DE@/opensearch-dashboards-highlighted-field@' created)"
    ]
  },
  "sort": [
    1725352154000
  ]

The example contains the following information:

• additional_info
• origin
• policy
• process

For more information about the various fields, refer here.

Policy Status Dashboard index

The policy status dashboard index contains information for the Policy Status Dashboard. It holds the policy and trusted application deployment status information. The index pattern for viewing these logs in Discover is pty_insight_analytics*policy_status_dashboard_*.

{
    "logtype": "Status",
    "process": {
      "thread_id": "2458884416",
      "module": "rpstatus",
      "name": "java",
      "pcc_version": "3.6.0.1",
      "id": "2852",
      "user": "root",
      "version": "10.0.0-alpha+13.gef09.10.0",
      "core_version": "2.1.0+17.gca723.2.1",
      "platform": "Linux_x64"
    },
    "origin": {
      "time_utc": "2024-09-03T10:24:19.000Z",
      "hostname": "ip-10-49-2-49.ec2.internal",
      "ip": "10.49.2.49"
    },
    "cnt": 1,
    "protector": {
      "vendor": "Java",
      "datastore": "DataStore",
      "family": "sdk",
      "version": "10.0.0-alpha+13.gef09.10.0"
    },
    "ingest_time_utc": "2024-09-03T10:24:19.510Z",
    "status": {
      "core_correlationid": "cm0f1jlq700gbzb19cq65miqt",
      "package_correlationid": "cm0m1tv5k0019te89e48tgdug"
    },
    "policystatus": {
      "type": "TRUSTED_APP",
      "application_name": "APJava_sample",
      "deployment_or_auth_time": "2024-09-03T10:24:19.000Z",
      "status": "WARNING"
    }
  },
  "fields": {
    "policystatus.deployment_or_auth_time": [
      "2024-09-03T10:24:19.000Z"
    ],
    "origin.time_utc": [
      "2024-09-03T10:24:19.000Z"
    ],
    "ingest_time_utc": [
      "2024-09-03T10:24:19.510Z"
    ]
  },
  "sort": [
    1725359059000
  ]

The example contains the following information:

• additional_info
• origin
• protector
• policystatus
• policy
• process

Protectors status index

The protector status logs generated by protectors are stored in this index. The index pattern for viewing these logs in Discover is pty_insight_analytics_protectors_status_*.

Use the following query in Discover to view these logs.

logtype:status

A sample log is shown here:

{
   "logtype":"Status",
   "process":{
      "thread_id":"2559813952",
      "module":"rpstatus",
      "name":"java",
      "pcc_version":"3.6.0.1",
      "id":"1991",
      "user":"root",
      "version":"10.0.0.2.91.5ec4b8b",
      "core_version":"2.1.0-alpha+24.g7fc71.2.1",
      "platform":"Linux_x64"
   },
   "origin":{
      "time_utc":"2024-07-30T07:22:41.000Z",
      "hostname":"ip-10-39-3-218.ec2.internal",
      "ip":"10.39.3.218"
   },
   "cnt":1,
   "protector":{
      "vendor":"Java",
      "datastore":"PPC-10.39.2.7",
      "family":"sdk",
      "version":"10.0.0.2.91.5ec4b8b"
   },
   "ingest_time_utc":"2024-07-30T07:22:41.745Z",
   "status":{
      "core_correlationid":"clz79lc2o004jmb29neneto8k",
      "package_correlationid":"clz82ijw00037k790oxlnjalu"
   }
}

The example contains the following information:

• additional_info
• origin
• policy
• protector

Protector Status Dashboard index

The protector status dashboard index contains information for the Protector Status Dashboard. It holds the protector status information. The index pattern for viewing these logs in Discover is pty_insight_analytics*protector_status_dashboard_.

A sample log is shown here:

{
    "logtype": "Status",
    "process": {
      "thread_id": "2458884416",
      "module": "rpstatus",
      "name": "java",
      "pcc_version": "3.6.0.1",
      "id": "2852",
      "user": "root",
      "version": "10.0.0-alpha+13.gef09.10.0",
      "core_version": "2.1.0+17.gca723.2.1",
      "platform": "Linux_x64"
    },
    "origin": {
      "time_utc": "2024-09-03T10:24:19.000Z",
      "hostname": "ip-10-49-2-49.ec2.internal",
      "ip": "10.49.2.49"
    },
    "cnt": 1,
    "protector": {
      "vendor": "Java",
      "datastore": "DataStore",
      "family": "sdk",
      "version": "10.0.0-alpha+13.gef09.10.0"
    },
    "ingest_time_utc": "2024-09-03T10:24:19.510Z",
    "status": {
      "core_correlationid": "cm0f1jlq700gbzb19cq65miqt",
      "package_correlationid": "cm0m1tv5k0019te89e48tgdug"
    },
    "protector_status": "Warning"
  },
  "fields": {
    "origin.time_utc": [
      "2024-09-03T10:24:19.000Z"
    ],
    "ingest_time_utc": [
      "2024-09-03T10:24:19.510Z"
    ]
  },
  "sort": [
    1725359059000
  ]

The example contains the following information:

• additional_info
• origin
• protector
• process

Miscellaneous index

The logs that are not added to the other indexes are captured and stored in the miscellaneous index. The index pattern for viewing these logs in Discover is pty_insight_analytics_miscellaneous_*.

This index should not contain any logs. If any logs are visible in this index, then kindly contact Protegrity support.

Use the following query in Discover to view these logs.

logtype:miscellaneous;

3.4.2.4 - Log return codes

3.4.2.5 - Protectors security log codes

The security logging level can be configured when a data security policy is created in the Policy management in PPC. If logging level is set to audit successful and audit failed, then both successful and failed Unprotect/Protect/Reprotect/Delete operations will be logged.

You can define the server where these security audit logs will be sent to. You can do that by modifying the Log Server configuration section in pepserver.cfg file.

If you configure to send protector security logs to the PPC, you will be able view them in Discover, by logging into the Insight Dashboard, selecting Discover from the menu, and selecting a time period such as Last 30 days. The following table displays the logs sent by protectors.

3.4.2.6 - Additional log information

These are values for understanding the values that are displayed in the log records.

Log levels

Most events on the system generate logs. The level of the log helps you understand whether the log is just an information message or denotes some issue with the system. The log message and the log level allows you to understand more about the working of the system and also helps you identify and troubleshoot any system issues.

Protection logs: These logs are generated for Unprotect, Reprotect, and Protect (URP) operations.

• SUCCESS: This log is generated for a successful URP operation.
• WARNING: This log is generated if a user does not have access and the operation is unprotect.
• EXCEPTION: This log is generated if a user does not have access, the operation is unprotect, and the return exception property is set.
• ERROR: This log is generated for all other issues.

Application logs: These logs are generated by the application. The log level denotes the severity level of the log, however, levels 1 and 6 are used for the log configuration.

• 1: OFF. This level is used to turn logging off.
• 2: SEVERE. This level indicates a serious failure that prevents normal program execution.
• 3: WARNING. This level indicates a potential problem or an issue with the system.
• 4: INFO. This level is used to display information messages about the application.
• 5: CONFIG. This level is used to display static configuration information that is useful during debugging.
• 6: ALL. This level is used to log all messages.

Policy logs: These logs are used for the policy logs.

• LOWEST
• LOW
• NORMAL
• HIGH
• CRITICAL
• N/A

Protector information

The information displayed in the Protector-related fields of the audit log are listed in the table.

All Protectors displayed here may not be compatible with this release. Refer to your contract for compatible products.

Modules and components and the log type

Some of the components and modules and the logtype that they generate are provided in the following table.

For more information and description about the components that can generate kernel logs, refer here.

Kernel logs

This section lists the various kernel logs that are generated.

Note: This list is compiled using information from https://pmhahn.github.io/audit/.

User and group account management:

• ADD_USER: A user-space user account is added.
• USER_MGMT: The user-space management data.
• USER_CHAUTHTOK: A user account attribute is modified.
• DEL_USER: A user-space user is deleted.
• ADD_GROUP: A user-space group is added.
• GRP_MGMT: The user-space group management data.
• GRP_CHAUTHTOK: A group account attribute is modified.
• DEL_GROUP: A user-space group is deleted.

User login live cycle events:

• CRYPTO_KEY_USER: The cryptographic key identifier used for cryptographic purposes.
• CRYPTO_SESSION: The parameters set during a TLS session establishment.
• USER_AUTH: A user-space authentication attempt is detected.
• LOGIN: The user log in to access the system.
• USER_CMD: A user-space shell command is executed.
• GRP_AUTH: The group password is used to authenticate against a user-space group.
• CHUSER_ID: A user-space user ID is changed.
• CHGRP_ID: A user-space group ID is changed.
• Pluggable Authentication Modules (PAM) Authentication:
  • USER_LOGIN: A user logs in.
  • USER_LOGOUT: A user logs out.
• PAM account:
  • USER_ERR: A user account state error is detected.
  • USER_ACCT: A user-space user account is modified.
  • ACCT_LOCK: A user-space user account is locked by the administrator.
  • ACCT_UNLOCK: A user-space user account is unlocked by the administrator.
• PAM session:
  • USER_START: A user-space session is started.
  • USER_END: A user-space session is terminated.
• Credentials:
  • CRED_ACQ: A user acquires user-space credentials.
  • CRED_REFR: A user refreshes their user-space credentials.
  • CRED_DISP: A user disposes of user-space credentials.

Linux Security Model events:

• DAC_CHECK: The record discretionary access control (DAC) check results.
• MAC_CHECK: The user space Mandatory Access Control (MAC) decision is made.
• USER_AVC: A user-space AVC message is generated.
• USER_MAC_CONFIG_CHANGE:
• SELinux Mandatory Access Control:
  • AVC_PATH: dentry and vfsmount pair when an SELinux permission check.
  • AVC: SELinux permission check.
  • FS_RELABEL: file system relabel operation is detected.
  • LABEL_LEVEL_CHANGE: object’s level label is modified.
  • LABEL_OVERRIDE: administrator overrides an object’s level label.
  • MAC_CONFIG_CHANGE: SELinux Boolean value is changed.
  • MAC_STATUS: SELinux mode (enforcing, permissive, off) is changed.
  • MAC_POLICY_LOAD: SELinux policy file is loaded.
  • ROLE_ASSIGN: administrator assigns a user to an SELinux role.
  • ROLE_MODIFY: administrator modifies an SELinux role.
  • ROLE_REMOVE: administrator removes a user from an SELinux role.
  • SELINUX_ERR: internal SELinux error is detected.
  • USER_LABELED_EXPORT: object is exported with an SELinux label.
  • USER_MAC_POLICY_LOAD: user-space daemon loads an SELinux policy.
  • USER_ROLE_CHANGE: user’s SELinux role is changed.
  • USER_SELINUX_ERR: user-space SELinux error is detected.
  • USER_UNLABELED_EXPORT: object is exported without SELinux label.
  • AppArmor Mandatory Access Control:
    • APPARMOR_ALLOWED
    • APPARMOR_AUDIT
    • APPARMOR_DENIED
    • APPARMOR_ERROR
    • APPARMOR_HINT
    • APPARMOR_STATUS APPARMOR

Audit framework events:

• KERNEL: Record the initialization of the Audit system.
• CONFIG_CHANGE: The Audit system configuration is modified.
• DAEMON_ABORT: An Audit daemon is stopped due to an error.
• DAEMON_ACCEPT: The auditd daemon accepts a remote connection.
• DAEMON_CLOSE: The auditd daemon closes a remote connection.
• DAEMON_CONFIG: An Audit daemon configuration change is detected.
• DAEMON_END: The Audit daemon is successfully stopped.
• DAEMON_ERR: An auditd daemon internal error is detected.
• DAEMON_RESUME: The auditd daemon resumes logging.
• DAEMON_ROTATE: The auditd daemon rotates the Audit log files.
• DAEMON_START: The auditd daemon is started.
• FEATURE_CHANGE: An Audit feature changed value.

Networking related:

• IPSec:
  • MAC_IPSEC_ADDSA
  • MAC_IPSEC_ADDSPD
  • MAC_IPSEC_DELSA
  • MAC_IPSEC_DELSPD
  • MAC_IPSEC_EVENT: The IPSec event, when one is detected, or when the IPSec configuration changes.
• NetLabel:
  • MAC_CALIPSO_ADD: The NetLabel CALIPSO DoI entry is added.
  • MAC_CALIPSO_DEL: The NetLabel CALIPSO DoI entry is deleted.
  • MAC_MAP_ADD: A new Linux Security Module (LSM) domain mapping is added.
  • MAC_MAP_DEL: An existing LSM domain mapping is added.
  • MAC_UNLBL_ALLOW: An unlabeled traffic is allowed.
  • MAC_UNLBL_STCADD: A static label is added.
  • MAC_UNLBL_STCDEL: A static label is deleted.
• Message Queue:
  • MQ_GETSETATTR: The mq_getattr and mq_setattr message queue attributes.
  • MQ_NOTIFY: The arguments of the mq_notify system call.
  • MQ_OPEN: The arguments of the mq_open system call.
  • MQ_SENDRECV: The arguments of the mq_send and mq_receive system calls.
• Netfilter firewall:
  • NETFILTER_CFG: The Netfilter chain modifications are detected.
  • NETFILTER_PKT: The packets traversing Netfilter chains.
• Commercial Internet Protocol Security Option:
  • MAC_CIPSOV4_ADD: A user adds a new Domain of Interpretation (DoI).
  • MAC_CIPSOV4_DEL: A user deletes an existing DoI.

Linux Cryptography:

• CRYPTO_FAILURE_USER: A decrypt, encrypt, or randomize cryptographic operation fails.
• CRYPTO_IKE_SA: The Internet Key Exchange Security Association is established.
• CRYPTO_IPSEC_SA: The Internet Protocol Security Association is established.
• CRYPTO_LOGIN: A cryptographic officer login attempt is detected.
• CRYPTO_LOGOUT: A cryptographic officer logout attempt is detected.
• CRYPTO_PARAM_CHANGE_USER: A change in a cryptographic parameter is detected.
• CRYPTO_REPLAY_USER: A replay attack is detected.
• CRYPTO_TEST_USER: The cryptographic test results as required by the FIPS-140 standard.

Process:

• BPRM_FCAPS: A user executes a program with a file system capability.
• CAPSET: Any changes in process-based capabilities.
• CWD: The current working directory.
• EXECVE; The arguments of the execve system call.
• OBJ_PID: The information about a process to which a signal is sent.
• PATH: The file name path information.
• PROCTITLE: The full command-line of the command that was used to invoke the analyzed process.
• SECCOMP: A Secure Computing event is detected.
• SYSCALL: A system call to the kernel.

Special system calls:

• FD_PAIR: The use of the pipe and socketpair system calls.
• IPC_SET_PERM: The information about new values set by an IPC_SET control operation on an Inter-Process Communication (IPC) object.
• IPC: The information about a IPC object referenced by a system call.
• MMAP: The file descriptor and flags of the mmap system call.
• SOCKADDR: Record a socket address.
• SOCKETCALL: Record arguments of the sys_socketcall system call (used to multiplex many socket-related system calls).

Systemd:

• SERVICE_START: A service is started.
• SERVICE_STOP: A service is stopped.
• SYSTEM_BOOT: The system is booted up.
• SYSTEM_RUNLEVEL: The system’s run level is changed.
• SYSTEM_SHUTDOWN: The system is shut down.

Virtual Machines and Container:

• VIRT_CONTROL: The virtual machine is started, paused, or stopped.
• VIRT_MACHINE_ID: The binding of a label to a virtual machine.
• VIRT_RESOURCE: The resource assignment of a virtual machine.

Device management:

• DEV_ALLOC: A device is allocated.
• DEV_DEALLOC: A device is deallocated.

Trusted Computing Integrity Measurement Architecture:

• INTEGRITY_DATA: The data integrity verification event run by the kernel.
• INTEGRITY_EVM_XATTR: The EVM-covered extended attribute is modified.
• INTEGRITY_HASH: The hash type integrity verification event run by the kernel.
• INTEGRITY_METADATA: The metadata integrity verification event run by the kernel.
• INTEGRITY_PCR: The Platform Configuration Register (PCR) invalidation messages.
• INTEGRITY_RULE: A policy rule.
• INTEGRITY_STATUS: The status of integrity verification.

Intrusion Prevention System:

• Anomaly detected:
  • ANOM_ABEND
  • ANOM_ACCESS_FS
  • ANOM_ADD_ACCT
  • ANOM_AMTU_FAIL
  • ANOM_CRYPTO_FAIL
  • ANOM_DEL_ACCT
  • ANOM_EXEC
  • ANOM_LINK
  • ANOM_LOGIN_ACCT
  • ANOM_LOGIN_FAILURES
  • ANOM_LOGIN_LOCATION
  • ANOM_LOGIN_SESSIONS
  • ANOM_LOGIN_TIME
  • ANOM_MAX_DAC
  • ANOM_MAX_MAC
  • ANOM_MK_EXEC
  • ANOM_MOD_ACCT
  • ANOM_PROMISCUOUS
  • ANOM_RBAC_FAIL
  • ANOM_RBAC_INTEGRITY_FAIL
  • ANOM_ROOT_TRANS
• Responses:
  • RESP_ACCT_LOCK_TIMED
  • RESP_ACCT_LOCK
  • RESP_ACCT_REMOTE
  • RESP_ACCT_UNLOCK_TIMED
  • RESP_ALERT
  • RESP_ANOMALY
  • RESP_EXEC
  • RESP_HALT
  • RESP_KILL_PROC
  • RESP_SEBOOL
  • RESP_SINGLE
  • RESP_TERM_ACCESS
  • RESP_TERM_LOCK

Miscellaneous:

• ALL: Matches all types.
• KERNEL_OTHER: The record information from third-party kernel modules.
• EOE: An end of a multi-record event.
• TEST: The success value of a test message.
• TRUSTED_APP: The record of this type can be used by third-party application that require auditing.
• TTY: The TTY input that was sent to an administrative process.
• USER_TTY: An explanatory message about TTY input to an administrative process that is sent from the user-space.
• USER: The user details.
• USYS_CONFIG: A user-space system configuration change is detected.
• TIME_ADJNTPVAL: The system clock is modified.
• TIME_INJOFFSET: A Timekeeping offset is injected to the system clock.

3.4.3 - Viewing the dashboards

The dashboards are build using visualization. Use the information from Viewing visualizations to customize and build dashboards.

Note: Do not clone, delete, or modify the configuration or details of the dashboards that are provided by Protegrity. To create a customized dashboard, first clone and customize the required visualizations, then create a dashboard, and place the customized visualizations on the dashboard.

To view a dashboard:

1. Log in to the Insight Dashboard.

2. From the navigation panel, click Dashboards.

3. Click the dashboard.

Viewing the Security Operation Dashboard

The security operation dashboard displays the counts of individual and total number of security operations for successful and unsuccessful operations. The Security Operation Dashboard has a table and pie charts that summarizes the security operations performed by a specific data store, protector family, and protector vendor. This dashboard shows different visualizations for the Successful Security Operations, Security Operations, Reprotect Counts, Successful Security Operation Counts, Security Operation Counts, Security Operation Table, and Unsuccessful Security Operations.

Note: This dashboard must not be deleted.

The dashboard has the following panels:

• Total Security Operations: Displays pie charts for for the successful and unsuccessful security operations:
  • Successful: Total number of security operations that succeeded.
  • Unsuccessful: Total number of security operations that was unsuccessful.
• Successful Security Operations: Displays pie chart for the following security operation:
  • Protect: Total number of protect operations.
  • Unprotect: Total number of unprotect operations.
  • Reprotect: Total number of reprotect operations.
• Unsuccessful Security Operations: Displays pie chart for the following security operation:
  • Error: Total number of operations that were unsuccessful due to an error.
  • Warning: Total number of operations that were unsuccessful due to a warning.
  • Exception: Total number of operations that were unsuccessful due to an exception.
• Total Security Operation Values: Displays the following information
  • Successful - Count: Total number of security operations that succeeded.
  • Unsuccessful - Count: Total number of security operations that were unsuccessful.
• Successful Security Operation Values: Displays the following information:
  • Protect - Count: Total number of protect operations.
  • Unprotect - Count: Total number of unprotect operations.
  • Reprotect - Count: Total number of reprotect operations.
• Unsuccessful Security Operation Values: Displays the following information:
  • ERROR - Count: Total number of error logs.
  • WARNING - Count: Total number of warning logs.
  • EXCEPTION - Count: Total number of exception logs.
• Security Operation Table: Displays the number of security operations done for a data store, protector family, protector vendor, and protector version.
• Unsuccessful Security Operations: Displays a list of unsuccessful security operations with details, such as, time, data store, protector family, protector vendor, protector version, IP, hostname, level, count, description, and source.

Viewing the Feature Usage Dashboard

The dashboard displays information about the Anonymization and Data Discovery features.

Note: This dashboard must not be deleted.

The dashboard has the following panels:

• Anonymization Information: Displays the job id, job status, total data processed in MB, and the data anonymized in MB.
• Data Discovery Information: Displays the status code, number of operations performed, and the sensitive data identified in MB.

Viewing the Protector Inventory Dashboard

The protector inventory dashboard displays protector details connected to the cluster through pie charts and tables. This dashboard has the Protector Details, Protector Families, Protector Vendor, Protector Version, Protector Core Version, and Protector Pcc Version visualizations. It is useful for understanding information about the installed Protectors.

Only protectors that perform security operations show up on the dashboard.

Note: This dashboard must not be deleted.

The dashboard has the following panels:

• Protector Details: Displays the list of protectors installed with information, such as, Protector Family, Protector Vendor, Protector Version, PCC Version, Protector Core Version, and Deployment count. The Deployment count is based on the number of unique IPs. Updating the IP address of the Protector will consider both the old and new entries for the protector.
• Protector Families: Displays pie chart with protector family information.
• Protector Vendor: Displays pie chart with protector vendor information.
• Protector Version: Displays pie chart with protector version information.
• Protector Core Version: Displays pie chart with protector core version information.
• Protector Pcc Version: Displays pie chart with protector Pcc version information.

Viewing the Protector Operation Dashboard

The protector operation dashboard displays protector details connected to the cluster through tables. This dashboard has the Protector Count and Protector List tables. It is useful for understanding information about the operations performed by the Protectors.

Only protectors that perform security operations show up on the dashboard. Updating the IP address or the hostname of the Protector shows the old and new entry for the protector.

Note: This dashboard must not be deleted.

The dashboard has the following panels:

• Protector Count: Displays the deployment count and operations performed for each Protector Family and Protector Vendor combination.
• Protector List: Displays the list of protection operations with information, such as, Protector Vendor, Protector Family, Protector Version, Protector IP, Hostname, Core Version, Pcc Version, and URP operations performed.

Viewing the Protector Status Dashboard

The protector status dashboard displays the protector connectivity status through a pie chart and a table visualization. This information is available only for v10.0.0 and later protectors. Logs from earlier protector versions are not available for the dashboards due to differences between the log formats. It is useful for understanding information about the installed v10.0.0 protectors. This dashboard uses status logs sent by the protector, so the protector which performed at least one security operation shows up on this dashboard. A protector is shown in one of the following states on the dashboard:

• OK: The latest logs are sent from the protector to the Audit Store within the last 15 minutes.
• Warning: The latest logs sent from the protector to the Audit Store in the last 15 and 60 minutes.
• Error: The latest logs sent from the protector to the Audit Store are more than 60 minutes.

Updating the IP address or the hostname of the protector shows the old and new entry for the protector.

Note: This dashboard shows the v10.0.0 protectors that are connected to the cluster. This dashboard must not be deleted.

The dashboard has the following panels:

• Connectivity Status: Displays a pie chart of the different states with the number of protectors that are in each state.
• Protector Status: Displays the list of protectors connectivity status with information, such as, Datastore, Node IP, Hostname, Protector Platform, Core Version, Protector Vendor, Protector Family, Protector Version, Status, and Last Seen.

Viewing the Policy Status Dashboard

The policy status dashboard displays the Policy and Trusted Application connectivity status with respective to a DataStore. The status information, on this dashboard, is updated every 10 minutes. It is useful to understand deployment of the DataStore on all protector nodes. This dashboard displays the Policy deploy Status, Trusted Application deploy status, Policy Deploy details, and Trusted Application details visualizations. This information is available only for v10.0.0 and later protectors.

The policy status logs are sent to Insight. These logs are stored in the policy status index that is pty_insight_analytics_policy. The policy status index is analyzed using the correlation ID to identify the unique policies received by the Audit Store. The time duration and the correlation ID are then analyzed for determining the policy status.

The dashboard uses status logs sent by the protectors about the deployed policy, so the Policy or Trusted Application used for at least one security operation shows up on this dashboard. A Policy and Trusted Application can be shown in one of the following states on the dashboard:

• OK: The latest correlation value of the logs sent for the Policy or Trusted Application to the Audit Store are within the last 15 minutes.
• Warning: The latest correlation value of the logs sent for the Policy or Trusted Application to the Audit Store are more than 15 minutes.

Note: This dashboard must not be deleted.

The dashboard has the following panels:

• Policy Deploy Status: Displays a pie chart of the different states with the number of policies that are in each state.
• Trusted Application Status: Displays a pie chart of the different states with the number of trusted applications that are in each state.
• Policy Deploy Details: Displays the list of policies and details, such as, Datastore Name, Node IP, Hostname, Last Seen, Policy Status, Process Name, Process Id, Platform, Core Version, PCC Version, Vendor, Family, Version, Deployment Time, and Policy Count.
• Trusted Application Details: Displays the list of policies for Trusted Applications and details, such as, Datastore Name, Node IP, Hostname, Last Seen, Policy Status, Process Name, Process Id, Platform, Core Version, PCC Version, Vendor, Family, Version, Authorize Time, and Policy Count.

Data Element Usage Dashboard

The dashboard shows the security operation performed by users according to data elements. It displays the top 10 data elements used for the top five users.

The following visualizations are displayed on the dashboard:

• Data Element Usage Intensity Of Users Per Protect operation
• Data Element Usage Intensity Of Users Per Unprotect operation
• Data Element Usage Intensity Of Users Per Reprotect operation

Sensitive Activity Dashboard

The dashboard shows the daily count of security events by data elements for specific time period.

The following visualization is displayed on the dashboard:

• Sensitive Activity By Date

Server Activity Dashboard

The dashboard shows the daily count of all events by servers for specific time period. The older Audit index entries are not displayed on a new installation.

The following visualizations are displayed on the dashboard:

• Server Activity of Troubleshooting Index By Date
• Server Activity of Policy Logs Index By Date
• Server Activity of Audit Index By Date

High & Critical Events Dashboard

The dashboard shows the daily count of system events of high and critical severity for selected time period. The older Audit index entries are not displayed on a new installation.

The following visualizations are displayed on the dashboard:

• System Report - High & Critical Events of Troubleshooting Index
• System Report - High & Critical Events of Policy Logs Index
• System Report - High & Critical Events of Older Audit Indices

The System Report - High & Critical Events of Older Audit Indices graph is for legacy protectors.

Signature Verification Dashboard

Logs are generated on the protectors. The log is then processed using the signature key and a hash value, and a checksum is generated for the log entry. The hash and the checksum is sent to Insight for storage and further processing. When the log entry is received by Insight, a check can be performed when the signature verification job is executed to verify the integrity of the logs.

The log entries having checksums are identified. These entries are then processed using the signature key and the checksum received in the log entry from the protector is checked. If both the checksum values match, then the log entry has not been tampered with. If a mismatch is found, then it might be possible that the log entry was tampered or there is an issue receiving logs from a protector. These can be viewed on the Discover screen by using the logtype:verification search criteria.

When the signature verification for an audit log fails, the failure logs are logged in Insight.

The following information is displayed on the dashboard:

• Time: Displays the date and time.
• Name: Displays the unique name for the signature verification job.
• Indexes: Displays the list of indexes on which the signature verification job runs.
• Query: Displays the signature verification query.
• Pending: Displays the number of logs pending for signature verification.
• Processed: Displays the current number of logs processed.
• Not-Verified: Displays the number of logs that could not be verified. Only protection logs are verified.
• Success: Displays the number of verifiable logs where signature verification succeeded.
• Failed: Displays the number of verifiable logs where signature verification failed.
• State: Displays the job status.

Support Logs Dashboard

The dashboard shows support logs required by support for troubleshooting. Filter the logs displayed using the Level, Pod, Container, and Namespace list.

Unauthorized Access Dashboard

The dashboard shows the cumulative counts of unauthorized access and activity by users into Protegrity appliances and protectors.

The following visualization is displayed on the dashboard:

• Unauthorized Access By Username

User Activity Dashboard

The dashboard shows the cumulative transactions performed by users over a date range.

The following visualization is displayed on the dashboard:

• User Activity Across Date Range

3.4.4 - Viewing visualizations

Note: Do not delete or modify the configuration or details of the visualizations provided by Protegrity. To customize the visualization, create a copy of the visualization and perform the customization on the copy of the visualization.

To view visualizations:

1. Log in to the Insight Dashboard.

2. From the navigation panel, click Visualize.

   Create and view visualizations from here.

3. Click a visualization to view it.

Anonymization Information

Description: The usage information for the Anonymization feature.

• Type: Date Table
• Configuration:
  • Index: pty_insight_analytics*anonymization_dashboard_*
  • Metrics:
    • Aggregation: Sum
    • Field: metrics.anon_bytes
    • Custom label: Data Anonymized
  • Buckets:
    • Split rows
      • Aggregation: Terms
      • Field: request.id.keyword
      • Order by: Metric: Data Anonymized
      • Order: Descending
      • Size: 9999
      • Custom label: Job Id
    • Split rows
      • Aggregation: Terms
      • Field: metrics.source_bytes
      • Order by: Metric: Data Anonymized
      • Order: Descending
      • Size: 9999
      • Custom label: Total Data

Data Discovery Information

Description: The usage information for the Data Discovery feature.

• Type: Date Table
• Configuration:
  • Index: pty_insight_analytics*discovery_dashboard_*
  • Metrics:
    • Aggregation: Count
    • Custom label: Operations Performed
  • Metrics:
    • Aggregation: Sum
    • Field: metrics.classified_bytes
    • Custom label: Sensitive Data Identified

User Activity Across Date Range

Description: The user activity during the date range specified.

• Type: Heat Map
• Filter: Audit Index Logtypes
• Configuration:
  • Index: pty_insight_analytics*audits_*
  • Metrics:
    • Value: Sum
    • Field: cnt
  • Buckets:
    • X-axis
      • Aggregation: Date Histogram
      • Field: origin.time_utc
      • Minimum interval: Day
    • Y-axis
      • Sub aggregation: Terms
      • Field: protection.policy_user.keyword
      • Order by: Metric:Sum of cnt
      • Order: Descending
      • Size: 10
      • Custom label: Policy Users

Sensitive Activity by Date

Description: The data element usage on a daily basis.

• Type: Line
• Filter: Audit Index Logtypes
• Configuration:
  • Index: pty_insight_analytics*audits_*
  • Metrics: Y-axis
    • Aggregation: Sum
    • Field: cnt
  • Buckets:
    • X-axis
      • Aggregation: Date Histogram
      • Field: origin.time_utc
      • Minimum interval: Day
      • Custom label: Date
    • Split series
      • Sub aggregation: Terms
      • Field: protection.dataelement.keyword
      • Order by: Metric:Sum of cnt
      • Order: Descending
      • Size: 10
      • Custom label: Operation Count

Unauthorized Access By Username

Description: Top 10 Unauthorized Protect and Unprotect operation counts per user.

• Type: Line
• Filter 1: Audit Index Logtypes
• Filter 2: protection.audit_code: is one of 1,3
• Configuration:
  • Index: pty_insight_analytics*audits_*
  • Metrics: Y-axis:
    • Aggregation: Sum
    • Field: cnt
  • Buckets:
    • X-axis
      • Aggregation: Terms
      • Field: protection.policy_user.keyword
      • Order by: Metric:Sum of cnt
      • Order: Descending
      • Size: 10
      • Custom label: Top 10 Policy Users
    • Split series
      • Sub aggregation: Filters
      • Filter 1-Protect: level=‘Error’
      • Filter 2-Unprotect: level=‘WARNING’

System Report - High & Critical Events of Audit Indices

Description: The chart reporting high and critical events from the Audit index.

• Type: Vertical Bar
• Filter: Severity Level : (High & Critical)
• Configuration:
  • Index: pty_insight_analytics*audits_*
  • Metrics: Y-axis:
    • Aggregation: Sum
    • Field: cnt
  • Buckets:
    • X-axis
      • Aggregation: Date Histogram
      • Field: origin.time_utc
      • Minimum Interval: Auto
      • Custom label: Date
    • Split series
      • Sub aggregation: Terms
      • Field: level.keyword
      • Order by: Metric:Sum of cnt
      • Order: Descending
      • Size: 10
    • Split series
      • Sub aggregation: Terms
      • Field: origin.hostname.keyword
      • Order by: Metric:Sum of cnt
      • Order: Descending
      • Size: 50
      • Custom label: Server

System Report - High & Critical Events of Policy Logs Index

Description: The chart reporting high and critical events from the Policy index.

• Type: Vertical Bar
• Filter: Severity Level : (High & Critical)
• Configuration:
  • Index: pty_insight_analytics*policy_log_*
  • Metrics: Y-axis:
    • Aggregation: Sum
    • Field: cnt
  • Buckets:
    • X-axis
      • Aggregation: Date Histogram
      • Field: origin.time_utc
      • Minimum Interval: Auto
      • Custom label: Date
    • Split series
      • Sub aggregation: Terms
      • Field: level.keyword
      • Order by: Metric:Sum of cnt
      • Order: Descending
      • Size: 20
    • Split series
      • Sub aggregation: Terms
      • Field: origin.hostname.keyword
      • Order by: Metric:Sum of cnt
      • Order: Descending
      • Size: 50
      • Custom label: Server

System Report - High & Critical Events of Troubleshooting Index

Description: The chart reporting high and critical events from the Troubleshooting index.

• Type: Vertical Bar
• Filter: Severity Level : (High & Critical)
• Configuration:
  • Index: pty_insight_analytics*troubleshooting_*
  • Metrics: Y-axis:
    • Aggregation: Sum
    • Field: cnt
  • Buckets:
    • X-axis
      • Aggregation: Date Histogram
      • Field: origin.time_utc
      • Minimum Interval: Auto
      • Custom label: Date
    • Split series
      • Sub aggregation: Terms
      • Field: level.keyword
      • Order by: Metric:Sum of cnt
      • Order: Descending
      • Size: 10
    • Split series
      • Sub aggregation: Terms
      • Field: origin.hostname.keyword
      • Order by: Metric:Sum of cnt
      • Order: Descending
      • Size: 50
      • Custom label: Server

Data Element Usage Intensity Of Users per Protect operation

Description: The chart shows the data element usage intensity of users per protect operation. It displays the top 10 data elements used by the top five users.

• Type: Heat Map
• Filter 1: protection.operation.keyword: Protect
• Filter 2: Audit Index Logtypes
• Configuration:
  • Index: pty_insight_analytics*audits_*
  • Metrics: Y-axis:
    • Aggregation: Sum
    • Field: cnt
  • Buckets:
    • X-axis
      • Aggregation: Terms
      • Field: protection.policy_user.keyword
      • Order by: Metric: Sum of cnt
      • Order: Descending
      • Size: 5
    • Y-axis
      • Sub aggregation: Terms
      • Field: protection.dataelement.keyword
      • Order by: Metric:Sum of cnt
      • Order: Descending
      • Size: 10

Data Element Usage Intensity Of Users per Reprotect operation

Description: The chart shows the data element usage intensity of users per reprotect operation. It displays the top 10 data elements used by the top five users.

• Type: Heat Map
• Filter 1: protection.operation.keyword: Reprotect
• Filter 2: Audit Index Logtypes
• Configuration:
  • Index: pty_insight_analytics*audits_*
  • Metrics: Y-axis:
    • Aggregation: Sum
    • Field: cnt
  • Buckets:
    • X-axis
      • Aggregation: Terms
      • Field: protection.policy_user.keyword
      • Order by: Metric: Sum of cnt
      • Order: Descending
      • Size: 5
    • Y-axis
      • Sub aggregation: Terms
      • Field: protection.dataelement.keyword
      • Order by: Metric:Sum of cnt
      • Order: Descending
      • Size: 10

Data Element Usage Intensity Of Users per Unprotect operation

Description: The chart shows the data element usage intensity of users per unprotect operation. It displays the top 10 data elements used by the top five users.

• Type: Heat Map
• Filter 1: protection.operation.keyword: Unprotect
• Filter 2: Audit Index Logtypes
• Configuration:
  • Index: pty_insight_analytics*audits_*
  • Metrics: Y-axis:
    • Aggregation: Sum
    • Field: cnt
  • Buckets:
    • X-axis
      • Aggregation: Terms
      • Field: protection.policy_user.keyword
      • Order by: Metric: Sum of cnt
      • Order: Descending
      • Size: 5
    • Y-axis
      • Sub aggregation: Terms
      • Field: protection.dataelement.keyword
      • Order by: Metric:Sum of cnt
      • Order: Descending
      • Size: 10

Server Activity of Audit Index By Date

Description: The chart shows the daily count of all events by servers for specific time period from the audit index.

• Type: Line
• Configuration:
  • Index: pty_insight_analytics*audits_*
  • Metrics: Y-axis:
    • Aggregation: Sum
    • Field: cnt
  • Buckets:
    • X-axis
      • Aggregation: Date Histogram
      • Field: origin.time_utc
      • Minimum interval: Day
    • Split series
      • Sub aggregation: Terms
      • Field: origin.hostname.keyword
      • Order by: Metric:Sum of cnt
      • Order: Descending
      • Size: 10

Server Activity of Policy Log Index By Date

Description: The chart shows the daily count of all events by servers for specific time period from the policy index.

• Type: Line
• Configuration:
  • Index: pty_insight_analytics*policy_log_*
  • Metrics: Y-axis:
    • Aggregation: Sum
    • Field: cnt
  • Buckets:
    • X-axis
      • Aggregation: Date Histogram
      • Field: origin.time_utc
      • Minimum interval: Day
    • Split series
      • Sub aggregation: Terms
      • Field: origin.hostname.keyword
      • Order by: Metric:Sum of cnt
      • Order: Descending
      • Size: 10

Server Activity of Troubleshooting Index By Date

Description: The chart shows the daily count of all events by servers for specific time period from the troubleshooting index.

• Type: Line
• Configuration:
  • Index: pty_insight_analytics*troubleshooting_*
  • Metrics: Y-axis:
    • Aggregation: Sum
    • Field: cnt
  • Buckets:
    • X-axis
      • Aggregation: Date Histogram
      • Field: origin.time_utc
      • Minimum interval: Day
    • Split series
      • Sub aggregation: Terms
      • Field: origin.hostname.keyword
      • Order by: Metric:Sum of cnt
      • Order: Descending
      • Size: 10

Connectivity status

Description: This pie chart display connectivity status for the protectors.

• Type: Pie
• Configuration:
  • Index: pty_insight_analytics*protector_status_dashboard_*
  • Metrics:
    • Slice size
      • Aggregation: Unique Count
      • Field: origin.ip
      • Custom label: Number
  • Buckets:
    • Split slices
      • Aggregation: Terms
      • Field: protector_status.keyword
      • Order by: Metric:Number
      • Order: Descending
      • Size: 10000

Policy_Deploy_Status_Chart

Description: This pie chart displays the deployment status of the policy.

• Type: Pie
• Filter: policystatus.type.keyword: POLICY
• Configuration:
  • Index: pty_insight_analytics*policy_status_dashboard_*
  • Metrics:
    • Slice size
      • Aggregation: Unique Count
      • Field: _id
  • Buckets:
    • Split slices
      • Aggregation: Terms
      • Field: policystatus.status.keyword
      • Order by: Metric:Unique Count of _id
      • Order: Descending
      • Size: 50
      • Custom label: Policy Status

Policy_Deploy_Status_Table

Description: This table displays the policy deployment status and uniquely identified information for the data store, protector, process, platform, node, and so on.

• Type: Data Table
• Filter: policystatus.type.keyword: POLICY
• Configuration:
  • Index: pty_insight_analytics*policy_status_dashboard_*
  • Metrics:
    • Aggregation: Count
    • Custom label: Metrics Count
  • Buckets:
    • Split rows
      • Aggregation: Terms
      • Field: protector.datastore.keyword
      • Order by: Metric: Metrics Count
      • Order: Descending
      • Size: 50
      • Custom label: Data Store Name
    • Split rows
      • Aggregation: Terms
      • Field: origin.ip
      • Order by: Metric: Metrics Count
      • Order: Descending
      • Size: 50
      • Custom label: Node IP
    • Split rows
      • Aggregation: Terms
      • Field: origin.hostname.keyword
      • Order by: Metric: Metrics Count
      • Order: Descending
      • Size: 50
      • Custom label: Host Name
    • Split rows
      • Aggregation: Terms
      • Field: policystatus.status.keyword
      • Order by: Metric: Metrics Count
      • Order: Descending
      • Size: 50
      • Custom label: Status
    • Split rows
      • Aggregation: Terms
      • Field: origin.time_utc
      • Order by: Metric: Metrics Count
      • Order: Descending
      • Size: 50
      • Custom label: Last Seen
    • Split rows
      • Aggregation: Terms
      • Field: process.name.keyword
      • Order by: Metric: Metrics Count
      • Order: Descending
      • Size: 50
      • Custom label: Process Name
    • Split rows
      • Aggregation: Terms
      • Field: process.id.keyword
      • Order by: Metric: Metrics Count
      • Order: Descending
      • Size: 50
      • Custom label: Process Id
    • Split rows
      • Aggregation: Terms
      • Field: process.platform.keyword
      • Order by: Metric: Metrics Count
      • Order: Descending
      • Size: 50
      • Custom label: Platform
    • Split rows
      • Aggregation: Terms
      • Field: process.core_version.keyword
      • Order by: Metric: Metrics Count
      • Order: Descending
      • Size: 50
      • Custom label: Core Version
    • Split rows
      • Aggregation: Terms
      • Field: process.pcc_version.keyword
      • Order by: Metric: Metrics Count
      • Order: Descending
      • Size: 50
      • Custom label: PCC Version
    • Split rows
      • Aggregation: Terms
      • Field: protector.version.keyword
      • Order by: Metric: Metrics Count
      • Order: Descending
      • Size: 50
      • Custom label: Protector Version
    • Split rows
      • Aggregation: Terms
      • Field: protector.vendor.keyword
      • Order by: Metric: Metrics Count
      • Order: Descending
      • Size: 50
      • Custom label: Vendor
    • Split rows
      • Aggregation: Terms
      • Field: protector.family.keyword
      • Order by: Metric: Metrics Count
      • Order: Descending
      • Size: 50
      • Custom label: Family
    • Split rows
      • Aggregation: Terms
      • Field: policystatus.deployment_or_auth_time
      • Order by: Metric: Metrics Count
      • Order: Descending
      • Size: 50
      • Custom label: Deployment Time

Protector Core Version

Description: This pie chart displays the counts of protectors installed for each protector core version.

• Type: Pie
• Configuration:
  • Index: pty_insight_analytics*audits_*
  • Metrics: Slice size
    • Aggregation: Unique Count
    • Field: origin.ip
  • Buckets:
    • Split slices
      • Aggregation: Terms
      • Field: protector.core_version.keyword
      • Order by: Metric:Unique count of origin.ip
      • Order: Descending
      • Size: 1000
      • Custom label:CoreVersion