Secure Storage of Connection Strings and Passwords in PI AF: Challenges and Solutions

In industrial automation and data infrastructure, the need to store sensitive credentials such as connection strings and passwords—especially when integrating PI AF (Asset Framework) with external services—is a common pain point. Getting it right is crucial for both system security and maintainability. Let’s explore the main considerations and commonly used solutions, along with their pros, cons, and practical advice.

The Problem: Secure Credential Storage in a Distributed Environment

When building integrations using the PI SDK, AFSDK, or custom data references, you may need to store and retrieve passwords or connection strings for various devices and external services. Ideally, you want to:

• Keep all system configuration and metadata—including credentials—centrally in PI AF for easy management
• Protect these credentials, so only authorized applications and users can access them
• Implement encryption at rest, satisfying audit and compliance requirements
• Address the challenge of distributed access, as multiple AF servers or clients might need the credentials

Tools like Windows DPAPI provide strong encryption mechanisms, but are inherently tied to either a machine or a user account. In a distributed environment—where multiple hosts and/or service accounts need access—using DPAPI directly often poses logistical obstacles due to secrets being bound to specific contexts.

Solution Options Overview

Let’s break down the main patterns, their advantages, and considerations:

1. DPAPI with Pre-Shared Key

Process: Generate a random encryption key, protect it using DPAPI for each host/service user, and use that key to encrypt/decrypt passwords stored in AF.

Advantages:

• Strong cryptographic primitives via DPAPI
• Encrypted values can be stored centrally in AF

Challenges:

• Must securely distribute and protect the pre-shared key
• Key management and rotation can be cumbersome

2. Restricting Access via AF Security

Process: Store the connection info in dedicated AF Elements or Attributes, and restrict read access (e.g., via Windows Integrated Security) so only specific service accounts or applications can access them.

Advantages:

• Simple to implement
• Centralizes management in AF
• Leverages mature Windows security mechanisms

Challenges:

• Does NOT provide encryption at rest; credentials are plain in the backend AF SQL DB
• Anyone with sufficient backend access could still access them

3. Combine Both Approaches

For enhanced security and auditing, organizations sometimes combine both methods:

• Encrypt sensitive data before storing in AF
• Place the (encrypted) values in security-restricted AF Attributes
• Manage key distribution and decryption carefully via a centralized vault or key management service

4. External Secret Management

Store credentials in a purpose-built secret management system such as:

• Azure Key Vault, AWS Secrets Manager, or Hashicorp Vault
• Reference the secret within PI AF using tokens, short-lived keys, or programmatic retrieval

Advantages:

• Centralized, audited, and designed for distributed access
• Supports key rotation and access policies

Drawbacks:

• Requires integration overhead and possibly cloud dependencies
• Adds complexity to the solution

Key Considerations and Best Practices

1. Don’t Store Secrets in Code: Never embed passwords or keys directly in code or configuration files alongside your application.
2. Encrypt at Rest and In Transit: Even with restricted access, encrypt credentials when feasible—especially for compliance.
3. Review Who Needs Access: Employ the principle of least privilege: limit who and what can access credentials.
4. Support Rotation and Updates: Ensure your approach supports safe, regular credential rotation—avoid hard-coding or manual replacements.
5. Consider Secret Expiry and Auditing: Use solutions that provide auditing and expiry features for enhanced ops and security.

Example: A Practical Approach

Suppose you have a PI AF-based system that must retrieve data from an external web service, authenticating with API keys and passwords. Here’s a robust process:

• Store encrypted credentials (using a strong encryption standard) as AF Attribute values
• Restrict access to those Attributes to the service account(s) only
• Store the encryption/decryption key in an enterprise vault or, if going lighter, use DPAPI to protect the key per host/service user
• On application startup, unseal the key, retrieve the credential from AF, decrypt, and use as needed
• Build/admin tooling to allow authorized personnel to rotate and update credentials

Conclusion

There’s no universal answer: the right choice depends on your environment, compliance needs, and operational constraints. For most PI AF deployments, combining encryption with AF security and considering an external secrets manager yields the best balance of usability and security.

What have you tried, and what works for you? Share your thoughts and experiences in the comments!