Credentials & Security Guide

🔐 Overview

Your SRS Integration Partner Services (SIPS) credentials are the keys to your integration. This guide outlines critical security requirements and best practices for managing your client_id and client_secret.

⚠️ CRITICAL: Mishandling credentials can result in unauthorized access, data breaches, financial loss, and integration suspension.

📋 What Are Your Credentials?

When you register with SIPS, you receive two pieces of information:

Credential	Type	Sensitivity	Purpose
`client_id`	Public identifier	🟡 Moderate	Identifies your application to SRS
`client_secret`	Secret key	🔴 CRITICAL	Authenticates your application identity

Think of it like this:

client_id = Your username (identifies who you are)

client_secret = Your password (proves you are who you say you are)

🚨 Security Requirements

✅ REQUIRED: Use Secrets Management Systems

Your credentials MUST be stored in a secure secrets management system:

Why Secrets Managers?

Benefit	Description
🔒 Encryption at Rest	Credentials stored encrypted in secure vaults
🔑 Access Control	Role-based permissions control who can read secrets
📜 Audit Logging	Track when and by whom credentials are accessed
🔄 Rotation Support	Automated credential rotation capabilities
🌐 Centralized Management	Single source of truth for all environments
🔐 No Plaintext Exposure	Credentials never stored in code or config files

❌ NEVER Store Credentials In:

❌ Location	Why It's Dangerous	Consequence
Source code files	Committed to version control, visible to all developers	Immediate security breach
Git repositories	History is permanent, even after deletion	Public exposure if repo leaked
Configuration files	Often checked into source control	Easy to accidentally commit
Plain text files	No encryption, easily readable	Direct access if server compromised
Environment variables (directly)	Visible in process listings, logs	Exposure through system monitoring
Hardcoded strings	Compiled into binaries, difficult to rotate	Impossible to change without redeployment
Email or chat messages	Unencrypted, stored indefinitely	Permanent record of credentials
Documentation	Screenshots, wikis, shared docs	Wide distribution, hard to revoke
Client-side code	JavaScript, mobile apps	Publicly accessible by end users

🔑 How to Properly Use Credentials

☁️ Pattern 1: Azure Key Vault (Recommended for Azure) - Click to expand

Store and Retrieve Credentials:

Store credentials in Azure Key Vault using az keyvault secret set

Retrieve at application startup using az keyvault secret show

Populate environment variables from Key Vault values

Use environment variables in your application

Key Benefits:

Centralized secret management

RBAC and access policies

Audit logging

Automated rotation support

☁️ Pattern 2: AWS Secrets Manager - Click to expand

Store and Retrieve Credentials:

Create secret using aws secretsmanager create-secret

Store both client_id and client_secret in JSON format

Retrieve at runtime using aws secretsmanager get-secret-value

Parse JSON and export to environment variables

Key Benefits:

Native AWS integration

Automatic rotation capabilities

Fine-grained IAM permissions

Cross-region replication

🔐 Pattern 3: HashiCorp Vault - Click to expand

Store and Retrieve Credentials:

Store credentials using vault kv put

Retrieve specific fields using vault kv get -field

Export to environment variables

Use Vault Agent for automatic renewal

Key Benefits:

Multi-cloud support

Dynamic secrets generation

Comprehensive audit trail

On-premises or cloud deployment

⚓ Pattern 4: Kubernetes Secrets - Click to expand

Store and Retrieve Credentials:

Create Kubernetes secret using kubectl create secret

Reference secret in Pod/Deployment spec

Mount as environment variables or files

Kubernetes manages secret lifecycle

Key Benefits:

Native Kubernetes integration

Namespace isolation

RBAC support

Automatic updates via volume mounts

🔄 Credential Rotation Policy

SRS Rotation Requirements

Policy	Frequency	Enforcement
Recommended Rotation	Every 90 days	Partner responsibility
Mandatory Rotation	Every 6 months	SRS enforced

⚠️ IMPORTANT: SRS will enforce credential rotation every 6 months. Plan ahead to avoid integration downtime.

🔄 Rotation Best Practices - Click to expand

Before Rotation:

✅ Test rotation process in Staging environment

✅ Document rotation procedures

✅ Identify all systems using credentials

✅ Schedule during low-traffic period

During Rotation:

✅ Request new credentials from SRS Support

✅ Update secrets in secrets manager (keep old credentials active)

✅ Deploy application updates to use new credentials

✅ Verify new credentials work in Production

✅ Monitor for errors

✅ Remove old credentials after verification

After Rotation:

✅ Update documentation with rotation date

✅ Set calendar reminder for next rotation

✅ Audit logs to confirm no usage of old credentials

✅ Archive old credentials securely (for audit purposes only)

🚫 What NOT to Do with Credentials

❌ Never Share Credentials With - Click to expand

End Users / Customers:

Your integration credentials are for your application only

Customers should never see or use your credentials

Each partner gets unique credentials

Third-Party Services:

Don't share credentials with contractors or vendors without SRS approval

Use separate credentials for different vendors if approved

Public Forums or Support Tickets:

Never include credentials in bug reports

Never post credentials in GitHub Issues or Stack Overflow

Only share client_id (not client_secret) when requesting support

Email, Slack, Teams, or Chat:

Don't send credentials via unencrypted communication

Use secure password sharing tools (1Password, LastPass) if absolutely necessary

🆘 Suspected Credential Compromise

⚠️ If you suspect your credentials have been compromised, exposed, or leaked, take immediate action.

🚨 Step 1: Contact SRS Immediately - Click to expand

SRS API Support Team:

📧 Email: APISupportTeam@srsdistribution.com

📋 Subject: URGENT: Suspected Credential Compromise - [Your Company Name]

Include in Your Report:

Your client_id (safe to share)

Your company name

Environment affected (Staging/Production)

How credentials were potentially exposed

When the exposure occurred

What actions you've already taken

🔍 Step 2: Investigate the Incident - Click to expand

Determine Scope:

✅ When were credentials exposed?

✅ Who had access to the exposed credentials?

✅ Were credentials used by unauthorized parties?

✅ What data was potentially accessed?

Review Access Logs:

Check API access logs for unusual activity

Look for unexpected IP addresses or usage patterns

Identify any unauthorized API calls

Document timeline of events

🔒 Step 3: Secure Your Environment - Click to expand

Immediately:

✅ Revoke compromised credentials (SRS will assist)

✅ Remove credentials from exposed location

✅ Block unauthorized access points

✅ Change all related passwords

Short-term:

✅ Request new credentials from SRS

✅ Update all systems with new credentials

✅ Verify proper secrets management is in place

✅ Monitor for suspicious activity

Long-term:

✅ Conduct security audit

✅ Implement additional access controls

✅ Train team on security best practices

✅ Document incident and lessons learned

📊 Step 4: Post-Incident Review - Click to expand

Required Documentation:

Incident timeline

Root cause analysis

Remediation steps taken

Prevention measures implemented

Share with SRS:

Summary of incident

Actions taken to prevent recurrence

Updated security procedures

🔐 Environment-Specific Credentials

Use Different Credentials for Each Environment

Environment	Purpose	Credential Set
Staging/QA	Testing and development	Staging credentials
Production	Live customer orders	Production credentials

❓ Why Separate Credentials? - Click to expand

✅ Limit Blast Radius: Compromised staging credentials don't affect production
✅ Access Control: Different teams can have different access levels
✅ Audit Trail: Clear separation of testing vs production activity
✅ Rotation Flexibility: Rotate production credentials without impacting testing

📋 Request Production Credentials - Click to expand

When to Request:

After successful integration testing in Staging

Ready to process live customer orders

Security review completed

How to Request:

Email APISupportTeam@srsdistribution.com

Include:

Company name

Staging client_id (for reference)

Confirmation that security requirements are met

Expected go-live date

Response Time: 1-2 business days

📊 Credential Access Control

Principle of Least Privilege

👥 Who Should Have Access - Click to expand

Roles with Access:

Role	Access Level	Justification
Production Engineers	Read production credentials	Deploy and maintain live systems
DevOps Team	Manage credentials in secrets manager	Infrastructure management
Security Team	Audit access logs	Security monitoring
Integration Developers	Read staging credentials only	Development and testing
Support Team	View `client_id` only (not secret)	Troubleshooting with SRS

Who Should NOT Have Access:

❌ Junior developers (use staging credentials)

❌ QA team (use staging credentials)

❌ Customer-facing support

❌ Sales and marketing teams

❌ Third-party contractors (without approval)

🔐 Access Control Best Practices - Click to expand

Implementation:

Use RBAC in your secrets management system

Grant minimum required permissions

Use service accounts for applications (not personal accounts)

Enable multi-factor authentication (MFA) for human access

Maintenance:

✅ Regularly review access permissions

✅ Remove access immediately when team members leave

✅ Audit access logs monthly

✅ Document all permission changes

📜 Audit & Compliance

📊 Monitor Credential Usage - Click to expand

Track the Following:

✅ When credentials are accessed

✅ Who accessed credentials

✅ What systems used credentials

✅ Failed authentication attempts

✅ Unusual access patterns

Set Up Alerts For:

🚨 Credentials accessed from unauthorized IP addresses

🚨 Failed authentication attempts exceeding threshold

🚨 Credentials accessed outside business hours

🚨 Multiple rapid authentication attempts

🔍 Regular Security Audits - Click to expand

Quarterly Review:

✅ Who has access to credentials

✅ Where credentials are stored

✅ Last rotation date

✅ Access log review

✅ Compliance with security policies

Annual Review:

✅ Comprehensive security assessment

✅ Penetration testing

✅ Credential management process review

✅ Incident response plan validation

🎓 Team Training

📚 Required Knowledge by Role - Click to expand

All Team Members:

✅ Never commit credentials to version control

✅ Never share credentials via insecure channels

✅ Report suspected compromises immediately

Developers:

✅ How to retrieve credentials from secrets manager

✅ Proper use of environment variables

✅ Secure coding practices

DevOps/Operations:

✅ Secrets manager administration

✅ Credential rotation procedures

✅ Monitoring and alerting setup

Security Team:

✅ Incident response procedures

✅ Audit log analysis

✅ Access control management

📚 Quick Reference Checklist

✅ Before Going Live

Credentials stored in secrets management system

Separate credentials for Staging vs Production

Access controls configured (least privilege)

Monitoring and alerting enabled

Team trained on security procedures

Incident response plan documented

Rotation schedule planned

Backup/recovery procedures tested

✅ Ongoing Maintenance

Rotate credentials every 90 days (recommended)

Review access logs monthly

Audit access permissions quarterly

Update security documentation

Test credential rotation process

Train new team members

✅ If Credentials Compromised

Contact SRS immediately

Revoke compromised credentials

Investigate incident scope

Update all affected systems

Document incident

Implement additional controls

Resource	Purpose	Link
Authentication Guide	How to authenticate with credentials	Authentication
Getting Started	Complete integration overview	Introduction
FAQ	Common questions and answers	FAQs

💬 Need Help?

Contact SRS API Support:

📧 Email: APISupportTeam@srsdistribution.com

When contacting support:

✅ Include your client_id (safe to share)

✅ Specify environment (Staging/Production)

❌ NEVER include your client_secret

Response Time: 1-2 business days

🔒 Remember: Your credentials are the keys to your integration. Treat them like you would your bank account password—with the highest level of security and care.

Last Updated: May 5, 2026

Credentials

Credentials & Security Guide#

🔐 Overview#

📋 What Are Your Credentials?#

🚨 Security Requirements#

✅ REQUIRED: Use Secrets Management Systems#

Recommended Solutions#

Why Secrets Managers?#

❌ NEVER Store Credentials In:#

🔑 How to Properly Use Credentials#

🔄 Credential Rotation Policy#

SRS Rotation Requirements#

🚫 What NOT to Do with Credentials#

🆘 Suspected Credential Compromise#

🔐 Environment-Specific Credentials#

Use Different Credentials for Each Environment#

📊 Credential Access Control#

Principle of Least Privilege#

📜 Audit & Compliance#

🎓 Team Training#

📚 Quick Reference Checklist#

✅ Before Going Live#

✅ Ongoing Maintenance#

✅ If Credentials Compromised#

🔗 Related Documentation#

💬 Need Help?#

Credentials & Security Guide

🔐 Overview

📋 What Are Your Credentials?

🚨 Security Requirements

✅ REQUIRED: Use Secrets Management Systems

Recommended Solutions

Why Secrets Managers?

❌ NEVER Store Credentials In:

🔑 How to Properly Use Credentials

🔄 Credential Rotation Policy

SRS Rotation Requirements

🚫 What NOT to Do with Credentials

🆘 Suspected Credential Compromise

🔐 Environment-Specific Credentials

Use Different Credentials for Each Environment

📊 Credential Access Control

Principle of Least Privilege

📜 Audit & Compliance

🎓 Team Training

📚 Quick Reference Checklist

✅ Before Going Live

✅ Ongoing Maintenance

✅ If Credentials Compromised

🔗 Related Documentation

💬 Need Help?