@cloudstreamsoftware/claude-tools 1.0.0 → 1.2.0

package/skills/compliance-patterns/pci-dss/zoho-checkout-patterns.md

@@ -0,0 +1,56 @@
+# PCI-DSS with Zoho Checkout
+
+## SAQ-A Compliance (Hosted Payment Pages)
+Using Zoho Checkout hosted pages means:
+- Cardholder data NEVER touches your systems
+- Simplified compliance (SAQ-A vs full SAQ-D)
+- Zoho handles PCI-DSS Level 1 compliance for payment processing
+- You only need to secure the redirect/iframe integration
+
+## Implementation Pattern
+```javascript
+// Widget: Redirect to Zoho Checkout hosted page
+function initiatePayment(orderId, amount) {
+  const checkoutConfig = {
+    amount: amount,
+    currency: 'USD',
+    order_id: orderId,
+    redirect_url: window.location.origin + '/payment-complete',
+    cancel_url: window.location.origin + '/payment-cancelled'
+  };
+
+  // Get checkout URL from Catalyst function (server-side)
+  fetch('/api/create-checkout-session', {
+    method: 'POST',
+    body: JSON.stringify(checkoutConfig)
+  })
+  .then(res => res.json())
+  .then(data => {
+    window.location.href = data.checkout_url; // Redirect to Zoho Checkout
+  });
+}
+```
+
+## Tokenization for Recurring
+```javascript
+// Catalyst function: Create subscription with token
+async function createSubscription(customerId, planId) {
+  const zohoPayments = new ZohoPaymentsAPI(await getValidToken());
+
+  // Token represents card - no PAN stored
+  const subscription = await zohoPayments.createSubscription({
+    customer_id: customerId,
+    plan_id: planId,
+    payment_method: 'token_from_checkout' // Never raw card data
+  });
+
+  return subscription;
+}
+```
+
+## What You MUST NOT Do
+- Store PAN (Primary Account Number) anywhere
+- Store CVV/CVC anywhere
+- Log card numbers (even partially in non-compliant systems)
+- Process payments server-side (use hosted pages)
+- Build custom payment forms (use Zoho Checkout)

package/skills/compliance-patterns/soc2/access-controls.md

@@ -0,0 +1,344 @@
+# SOC 2 Access Controls
+
+## Overview
+
+SOC 2 Trust Service Criteria CC6.1-CC6.8 require logical and physical access controls that restrict access to information assets to authorized users only. In Zoho Creator, this means implementing role-based access at the form, field, and record level, combined with comprehensive access review processes.
+
+> **WARNING**: SOC 2 auditors will request evidence of access reviews, role documentation, and access change logs. "We set it up correctly" is insufficient -- you must prove ongoing governance.
+
+---
+
+## Role-Based Access in Zoho Creator
+
+### Creator Permission Hierarchy
+
+```
+Organization Level (Zoho One Admin)
+    |
+    +-- Application Level (App Owner, App Admin, App User)
+    |       |
+    |       +-- Form Level (Add, Edit, View, Delete per role)
+    |       |       |
+    |       |       +-- Field Level (Show/Hide per role)
+    |       |               |
+    |       |               +-- Record Level (Creator permissions + custom filters)
+    |
+    +-- Portal Level (External users with limited access)
+```
+
+### Standard Role Template
+
+| Role | Typical Access | Creator Mapping |
+|---|---|---|
+| System Admin | Full access, configuration | App Owner |
+| Manager | All records, reports, approval | App Admin with custom permissions |
+| Standard User | Own records + team records | App User with filtered views |
+| Read-Only | View assigned records only | App User, view-only permissions |
+| External (Portal) | Limited self-service | Portal user with form-level access |
+| Service Account | API access only | API key with scoped permissions |
+| Auditor | Read-only, all historical data | Custom role, time-limited |
+
+---
+
+## Principle of Least Privilege Implementation
+
+### Step 1: Document Required Access Per Role
+
+Before configuring permissions, create an access requirements matrix:
+
+```
+| Form Name | Admin | Manager | User | Read-Only | Portal |
+|---|---|---|---|---|---|
+| Client_Records | CRUD | CRUD | CR | R | - |
+| Invoices | CRUD | CRUD | R | R | R(own) |
+| Audit_Logs | R | - | - | - | - |
+| System_Config | CRUD | R | - | - | - |
+| User_Requests | CRUD | CRUD | CRU(own) | R(own) | C(own) |
+```
+
+Legend: C=Create, R=Read, U=Update, D=Delete, (own)=own records only
+
+### Step 2: Configure Form-Level Permissions
+
+```deluge
+// Document permission configuration in code comments
+// Form: Client_Records
+// Permissions configured via Creator UI → Form Properties → Permissions
+//
+// Admin: Add, Edit, View, Delete, Export, Share
+// Manager: Add, Edit, View, Delete (no Export, no Share)
+// User: Add, View (own records only via criteria)
+// Read-Only: View (assigned records via lookup)
+// Portal: No access
+```
+
+### Step 3: Implement Field-Level Restrictions
+
+For sensitive fields within accessible forms:
+
+| Field | Admin | Manager | User | Rationale |
+|---|---|---|---|---|
+| SSN | View/Edit | View (masked) | Hidden | PII - need to know only |
+| Salary | View/Edit | View | Hidden | Confidential |
+| Internal_Notes | View/Edit | View/Edit | Hidden | Internal only |
+| Created_By | View | View | View | Audit field |
+| Modified_Date | View | View | View | Audit field |
+
+---
+
+## Quarterly Access Review Process
+
+### Review Schedule
+
+| Quarter | Review Type | Scope |
+|---|---|---|
+| Q1 (Jan) | Full access review | All users, all roles, all forms |
+| Q2 (Apr) | Privileged access review | Admin and Manager roles only |
+| Q3 (Jul) | Full access review | All users, all roles, all forms |
+| Q4 (Oct) | Annual certification | Full review + management sign-off |
+
+### Review Procedure
+
+1. **Export current access list** from Zoho Creator Admin Panel
+2. **Compare** against approved access matrix
+3. **Identify** discrepancies:
+   - Users with access who should not have it
+   - Users missing access they should have
+   - Dormant accounts (no login in 90+ days)
+   - Role creep (accumulated permissions beyond need)
+4. **Remediate** within 5 business days of identification
+5. **Document** findings and actions in the Access Review Log
+6. **Obtain** manager sign-off on review completion
+
+### Access Review Form Template
+
+```
+Form: Access_Review_Log
+Fields:
+  - Review_ID (Auto-number)
+  - Review_Date (Date)
+  - Review_Quarter (Picklist: Q1/Q2/Q3/Q4)
+  - Reviewer (Lookup to Employees)
+  - User_Reviewed (Email)
+  - Current_Role (Single Line)
+  - Appropriate (Yes/No)
+  - Action_Required (Picklist: None/Modify/Revoke/Investigate)
+  - Action_Taken (Multi Line)
+  - Action_Date (Date)
+  - Approved_By (Lookup to Managers)
+```
+
+---
+
+## Access Request/Approval Workflow
+
+### Request Process
+
+```
+User/Manager submits Access Request
+    |
+    v
+Auto-assigned to IT Admin for initial review
+    |
+    v
+IT Admin validates business justification
+    |
+    +-- Denied --> Notify requester with reason
+    |
+    +-- Approved --> Route to Data Owner for form-specific approval
+                        |
+                        v
+                    Data Owner reviews
+                        |
+                        +-- Denied --> Notify requester
+                        |
+                        +-- Approved --> IT Admin provisions access
+                                            |
+                                            v
+                                        Confirmation to requester + audit log entry
+```
+
+### Access Request Form
+
+```deluge
+// On submission of Access_Request form
+// Auto-route based on requested access level
+
+if (input.Access_Level == "Admin" || input.Access_Level == "Manager") {
+    // Elevated access requires additional approval
+    input.Approval_Chain = "IT Admin → Data Owner → Security Officer";
+    input.SLA_Hours = 48;
+} else {
+    input.Approval_Chain = "IT Admin → Data Owner";
+    input.SLA_Hours = 24;
+}
+
+// Log the request
+audit_entry = insert into HIPAA_Audit_Log [
+    Action_Type = "Access Request",
+    User_Email = zoho.loginuserid,
+    Form_Name = "Access_Request",
+    Record_ID = input.ID,
+    Justification = input.Business_Justification
+];
+```
+
+---
+
+## Privileged Access Monitoring
+
+### What Constitutes Privileged Access
+
+- Application Owner/Admin roles
+- Direct database access (if applicable)
+- API keys with write permissions
+- Access to configuration/settings forms
+- Access to audit log forms
+- Ability to modify workflows/permissions
+
+### Monitoring Requirements
+
+| Activity | Monitoring Method | Alert Threshold |
+|---|---|---|
+| Admin login | Audit log review | Any login outside business hours |
+| Permission changes | Workflow trigger on role modification | Any change |
+| Bulk data export | Export event logging | Any export > 100 records |
+| Schema changes | Form modification tracking | Any change to production forms |
+| API key usage | API call logging | Unusual volume or new IP |
+| User creation | New user event | Any new admin-level user |
+
+---
+
+## Separation of Duties (Dev vs. Prod)
+
+> **WARNING**: SOC 2 requires that developers cannot directly modify production systems without approval. Zoho Creator does NOT enforce this natively -- you must implement it procedurally.
+
+### Environment Separation
+
+| Environment | Purpose | Who Has Access | Restrictions |
+|---|---|---|---|
+| Development | Building/testing | Developers | No real data |
+| Staging | UAT/validation | Developers + Testers | Synthetic data only |
+| Production | Live operations | Operators + End Users | No direct dev access |
+
+### Promotion Process
+
+1. Developer completes work in Development org
+2. Developer submits Change Request (see `soc2/change-management.md`)
+3. Reviewer validates in Staging
+4. Approver authorizes production deployment
+5. **Different person** (not the developer) deploys to Production
+6. Post-deployment verification by Operations
+
+---
+
+## Service Account Management
+
+### Service Account Inventory
+
+```json
+{
+  "service_accounts": [
+    {
+      "name": "archival-service",
+      "purpose": "Monthly audit log archival to BigQuery",
+      "created_date": "2024-03-15",
+      "owner": "devops@cloudstreamsoftware.com",
+      "permissions": ["Creator API Read", "BigQuery Write"],
+      "key_rotation": "90 days",
+      "last_rotated": "2025-01-10",
+      "next_rotation": "2025-04-10"
+    }
+  ]
+}
+```
+
+### Service Account Rules
+
+- Every service account must have a documented owner
+- API keys rotated every 90 days minimum
+- Permissions scoped to minimum required
+- Usage monitored for anomalies
+- Disabled immediately when no longer needed
+- Never shared between environments (dev/staging/prod)
+
+---
+
+## MFA Enforcement
+
+### Requirements
+
+- **All users**: MFA required for Zoho One login
+- **Admin users**: Hardware key (FIDO2) preferred, TOTP acceptable
+- **Portal users**: TOTP or SMS (SMS only if TOTP not feasible)
+- **Service accounts**: IP restriction + API key (MFA not applicable)
+
+### Configuration
+
+```
+Zoho One Admin → Security → Multi-Factor Authentication
+→ Enable for all users
+→ Set enforcement: "Mandatory"
+→ Allowed methods: Authenticator App, Security Key
+→ Grace period for setup: 7 days
+→ Backup codes: Enabled (stored securely by IT)
+```
+
+---
+
+## Access Revocation on Employee Departure
+
+### Immediate Revocation Checklist (Within 4 Hours of Departure)
+
+- [ ] Disable Zoho One account
+- [ ] Revoke all API keys associated with the user
+- [ ] Remove from all Creator applications
+- [ ] Remove from all shared forms/reports
+- [ ] Remove from all portal access
+- [ ] Revoke GCP IAM permissions
+- [ ] Rotate any shared credentials the user knew
+- [ ] Remove from distribution lists/groups
+- [ ] Document revocation in Access Review Log
+- [ ] Verify revocation with login attempt test
+
+### Offboarding Workflow
+
+```deluge
+// Triggered by HR when employee status changes to "Terminated"
+// This initiates the access revocation workflow
+
+if (input.Employment_Status == "Terminated") {
+    // Create revocation task
+    revocation_task = insert into Access_Revocation [
+        Employee_Email = input.Email,
+        Departure_Date = zoho.currentdate,
+        Urgency = "Immediate",
+        Assigned_To = "it-admin@cloudstreamsoftware.com",
+        SLA_Hours = 4,
+        Status = "Pending"
+    ];
+
+    // Alert IT Admin
+    sendmail [
+        to: "it-admin@cloudstreamsoftware.com",
+        subject: "URGENT: Access Revocation Required - " + input.Full_Name,
+        message: "Employee departure. Revoke all access within 4 hours."
+    ];
+}
+```
+
+---
+
+## Access Matrix Documentation Template
+
+### Per-Client Access Matrix
+
+Maintain this document for each client engagement and update with every access change:
+
+| User | Role | Forms Accessible | Field Restrictions | Record Scope | Granted Date | Approved By | Last Reviewed |
+|---|---|---|---|---|---|---|---|
+| admin@client.com | Admin | All | None | All | 2024-03-01 | CEO | 2025-01-15 |
+| user1@client.com | User | Orders, Products | No cost fields | Own department | 2024-06-15 | Dept Mgr | 2025-01-15 |
+| portal@vendor.com | Portal | PO_Submissions | Limited fields | Own records | 2024-09-01 | Procurement Mgr | 2025-01-15 |
+
+> **WARNING**: This matrix must be stored in the client's compliance folder and presented during SOC 2 audits. Missing or outdated access matrices are audit findings.