Forem: Jonathan Wong

Technical Deep Dive: How I Delivered Zero Trust Security for a Client’s Legacy PHP System — Without Rewrites, Downtime, or...

Jonathan Wong — Tue, 14 Apr 2026 19:26:40 +0000

This section expands on the technical architecture and implementation behind my recent Zero Trust case study: How I Delivered Zero Trust Security for a Client’s Legacy PHP System — Without Rewrites, Downtime, or Big Costs – Behind the Build

Below is the high‑level architecture diagram:

AWS Layer — Role‑Based Access + Network Isolation

The AWS environment is built around least privilege, no public exposure, and segmented trust boundaries. We enforce this through IAM roles, security groups, resource‑level permissions, and Cloudflare Tunnel.

Resources

1. EC2 (api-production) — API Server with No Public IP

This EC2 instance runs the PHP API and sits entirely inside a private subnet. It has no public IP, no inbound rules, and no exposed ports. The only way it communicates with the internet is through Cloudflare Tunnel.

Cloudflare Tunnel works because:

The EC2 instance initiates an outbound TLS connection to Cloudflare
Cloudflare never needs to reach into AWS
No public IP, no inbound SG rules, and no NAT Gateway are required

This outbound‑only model eliminates the attack surface while still allowing global access.
Cloudflare Tunnel setup:

A. Install the cloudflared

curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg \
| sudo tee /usr/share/keyrings/cloudflare.gpg >/dev/null 

echo "deb [signed-by=/usr/share/keyrings/cloudflare.gpg] https://pkg.cloudflare.com/cloudflared jammy main" \
| sudo tee /etc/apt/sources.list.d/cloudflared.list  

sudo apt update
sudo apt install cloudflared

B. Cloudflare Login and authentication. This command generates a one‑time login URL that authenticates your machine with Cloudflare and authorizes this cloudflared instance. During the process, Cloudflare downloads a “cert.pem” file, which the CLI uses later when creating and managing tunnels.

// Please log in to your Cloudflare dashboard before running the command below. Otherwise, you will be redirected to the Cloudflare login page and the authentication flow will not complete.  

cloudflared tunnel login

C. Create Cloudflare tunnel. This command create Cloudflare tunnel, and returns a tunnel ID in the format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx1234
## Make sure to copy the tunnel ID for use in subsequent configuration steps

cloudflared tunnel create api-production-cf-tunnel

E. Create tunnel DNS record. This command creates the DNS record for in Cloudflare. You should see a new ‘tunnel’ DNS record appear automatically in the Cloudflare dashboard. There is no need to manually add the record yourself.

cloudflared tunnel route dns api-production-cf-tunnel yourdomain.com with value xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx1234.cfargotunnel.com

D. Create tunnel runtime configurations

nano ~/.cloudflared/config.yaml

The settings

tunnel: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx1234        # The tunnel ID returned by Cloudflare
credentials-file: /etc/cloudflared/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx1234.json  # Tunnel credentials

ingress:
  - hostname: yourdomain.com                        # Public hostname
    service: http://localhost:80                    # Local service to forward to
  - service: http_status:404                        # Default fallback

F. Start the Cloudflare tunnel

## save the configuration  
sudo mkdir -p /etc/cloudflared 
sudo mv ~/.cloudflared/config.yml /etc/cloudflared/
sudo mv ~/.cloudflared/*.json /etc/cloudflared/  
sudo chown root:root /etc/cloudflared/config.yml
sudo chown root:root /etc/cloudflared/.json 
sudo chmod 600 /etc/cloudflared/.json
sudo chmod 600 /etc/cloudflared/config.yml  

## start the cloudflare tunnel in the api-production (EC2) 
cloudflared tunnel run api-production-cf-tunnel

G. Install cloudflared as service

sudo cloudflared service install  
sudo systemctl enable cloudflared
sudo systemctl start cloudflared
sudo systemctl status cloudflared

2. RDS (rds-production) — Private MySQL Database
The production database is fully isolated:

No public access
No internet routing
IAM authentication only
Encryption enabled

It can only be reached through the RDS Proxy.

3. RDS Proxy (rds-proxy-production) — IAM‑Authenticated Database Access
The proxy sits between the EC2 instance and the database. It enforces:

IAM authentication
Connection pooling
No direct database exposure

IAM Roles

1. role-ec2-production — API Server Role
Attached to the EC2 instance. It grants access only to:

Specific S3 buckets
The RDS Proxy
CloudWatch logs

No IAM users, no access keys, no long‑lived credentials. The inline policy:

role-ec2-production Inline Policy

//  RDS  
{
  "Effect": "Allow",
  "Action": [
    "rds-db:connect"
  ],
  "Resource": [
    "arn:aws:rds-db:aws-region:aws-ac-id:dbuser:db-instance-arn/role-rds-db",
    "arn:aws:rds-db:aws-region:aws-ac-id:dbuser:prx-proxy-arn/role-rds-db"
  ]
}
//  S3  
{
  "Sid": "AllowListBucket",
  "Effect": "Allow",
  "Action": "s3:ListBucket",
  "Resource": "arn:aws:s3:::bucket-name",
  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": "aws-region"
    }
  }
},
{
  "Sid": "AllowObjectReadWrite",
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject"
  ],
  "Resource": "arn:aws:s3:::bucket-name/*",
  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": "aws-region"
    }
  }
}
//  CloudWatch  
{
  "Effect": "Allow",
  "Action": [
    "logs:DescribeLogGroups",
    "logs:DescribeLogStreams",
    "logs:CreateLogGroup",
    "logs:CreateLogStream",
    "logs:PutLogEvents"
  ],
  "Resource": "*"
}
//  JWT  
{
  "Sid": "AllowJWTPrivateKey",
  "Effect": "Allow",
  "Action": [
    "ssm:GetParameter",
    "ssm:GetParameters"
  ],
  "Resource": "arn:aws:ssm:aws-region:aws-ac-id:parameter/category-name/jwt/private-key"
}

2. role-rds-db — RDS Proxy Role
Attached to the RDS Proxy. It allows the proxy to authenticate to the database using IAM auth. Tokens are generated and signed by AWS KMS.

role-rds-db Inline policy

{
  "Sid": "GetSecretValue",
  "Action": [
    "secretsmanager:GetSecretValue"
  ],
  "Effect": "Allow",
  "Resource": [
    "arn:aws:secretsmanager:aws-region:aws-ac-id:secret:rds-proxy-role-rds-db-name"
  ]
}
{
  "Sid": "DecryptSecretValue",
  "Action": [
    "kms:Decrypt"
  ],
  "Effect": "Allow",
  "Resource": [
    "arn:aws:kms:aws-region:aws-ac-id:key/decrypt-key"
  ],
  "Condition": {
    "StringEquals": {
      "kms:ViaService": "secretsmanager.aws-region.amazonaws.com"
    }
  }
}
{
  "Effect": "Allow",
  "Action": "rds-db:connect",
  "Resource": "arn:aws:rds-db:aws-region:aws-ac-id:dbuser:db-name/role-rds-db"
}

3. role-rds-db — Database IAM Auth User
The same IAM auth username must exist inside the MySQL database. Creation SQL:

-- 1. Create IAM-authenticated user (no password)
CREATE USER 'role-rds-db'@'%' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';

-- 2. Grant only SELECT, INSERT, UPDATE, DELETE on the your_db database
GRANT SELECT, INSERT, UPDATE, DELETE ON your_db.* TO 'role-rds-db'@'%';

-- 3. Reload privileges (optional but safe)
FLUSH PRIVILEGES;

This ensures the proxy can authenticate as a database user without passwords.

Security Groups

1. sg-ec2-production

Attached to the api-production
No inbound access except from the bastion host via private IP
Outbound allowed for Cloudflare Tunnel

This removes the external attack surface entirely.

2. sg-rds-proxy

Attached to the RDS Proxy
Only allows inbound 3306 from sg-ec2-production

3. sg-rds-db

Attached to the RDS instance
Only allows inbound 3306 from sg-rds-proxy

This ensures:

EC2 cannot reach the database directly
Only the proxy can communicate with the database
Even inside the private network, lateral movement is blocked

API Server — PHP Layer

1. JWT validation and authorization in the PHP API before processing any request

The PHP API verifies the JWT signature
enforces expiration
checks user permissions directly from the claims

Generate JWT Code Snippet

// your function 

// -------------------------------
// 1. Load RSA private key from SSM
// -------------------------------

$ssm = new SsmClient([
    'region'  => 'aws-region',
    'version' => 'latest'
]);

$result = $ssm->getParameter([
    'Name' => '/category-name/jwt/private-key',   // <-- your parameter name
    'WithDecryption' => true
]);

$privateKeyPem = $result['Parameter']['Value'];

$privateKey = openssl_pkey_get_private($privateKeyPem);

if (!$privateKey) {
    
    //  error handling  
}

// -------------------------------
// 2. Helper: Base64URL encoding
// -------------------------------

function base64UrlEncode($data) {
    return rtrim(strtr(base64_encode($data), '+/', '-_'), '=');
}

// -------------------------------
// 3. Build JWT header + payload
// -------------------------------

$header = [
    'alg' => 'RS256',
    'typ' => 'JWT'
];

$payload = [
    "sub" => $sub,  //  variable for later checking  
    "iat" => time(),
    "exp" => time() + 360000,
    "iss" => "yourdomain.com",
    "aud" => "cloudflare"
];

$base64Header  = base64UrlEncode(json_encode($header, JSON_UNESCAPED_SLASHES));
$base64Payload = base64UrlEncode(json_encode($payload, JSON_UNESCAPED_SLASHES));

$dataToSign = "$base64Header.$base64Payload";

// -------------------------------
// 4. Sign with RSA private key
// -------------------------------

if (!openssl_sign($dataToSign, $signature, $privateKey, OPENSSL_ALGO_SHA256)) {
    
    //  error handling  
}

$jwt = $dataToSign . "." . base64UrlEncode($signature);  

// other function logic

Validate JWT Code Snippet

//  your function  

list($h, $p, $s) = explode('.', $jwt);

$dataToVerify = "$h.$p";
$signature    = base64UrlDecode($s);

$publicKey = openssl_pkey_get_public(file_get_contents(your_jwt_public_key_path));

// validate signature  
$valid = openssl_verify($dataToVerify, $signature, $publicKey, OPENSSL_ALGO_SHA256);

if ($valid !== 1) { 

    // error handling  

}  

$payload = json_decode(base64UrlDecode($p), true);  

// validate payload 
if (!$payload || !isset($payload['exp'])) {

    // error handling  

}

// validate expiry 
if (time() <= $payload['exp']) { 

    // error handling  
    
}  

//  your function other logic

2. Secure database access

All database operations use PDO’s native parameter binding, which inherently prevents SQL injection.
The connection enforces TLS encryption with the RDS CA bundle, ensuring data in transit is protected and the server identity is verified. The RDS CA bundle can be downloaded here
Authentication is fully passwordless using IAM role–based RDS authentication, so no credentials are stored in the application.
The PHP layer is restricted to connect exclusively through the RDS Proxy, never directly to the RDS instance, enforcing a strict Zero Trust boundary.

Database Connection Code Snippet

//  your function 

$host = "proxy-xxxxxxxx"; // RDS Proxy endpoint
$port = 3306;
$username = "role-rds-db"; // MySQL user created with IDENTIFIED WITH AWSAuthenticationPlugin
$region = "aws-region";
$dbname = "your_db";

// AWS SDK
$sdk = new Sdk([
    'region'   => $region,
    'version'  => 'latest'
]);  

$provider = CredentialProvider::defaultProvider();  

$rdsAuthGenerator = new AuthTokenGenerator($provider);

// Generate IAM token (no password stored)
$token = $rdsAuthGenerator->createToken("$host:$port", $region, $username);  

$dsn = "mysql:host=$host;port=$port;dbname=$dbname;charset=utf8mb4";  

// Enforces TLS encryption with the RDS CA bundle  
$ca_bundle_path = realpath($path_to_store_ . "/cert/global-bundle.pem");

$options = [
    PDO::ATTR_PERSISTENT         => false,                  // Disable persistence in PDO  
    PDO::ATTR_ERRMODE            => PDO::ERRMODE_EXCEPTION, // Throw exceptions on errors    
    PDO::MYSQL_ATTR_SSL_CA       => $ca_bundle_path,       // Path to RDS CA bundle  
//  other option settings  
];

try {
    // 3. Establish the connection
    $pdo = new PDO($dsn, $username, $token, $options);
    
    return $pdo;  
    
} catch (PDOException $e) {
    //  error handling  
}  

//  other function logic

3. No direct file handling on the server — The API never accepts file uploads. All file operations are performed through S3 pre‑signed URLs, ensuring the PHP layer remains stateless and free from file‑system exposure

S3 Upload / Read Code Snippet

//  your upload function  

$bucket = 'your-bucket';
$region = 'aws-region';
$subFolder = 'your-subFolder';  
//  $contentType as parameter  

$s3 = new S3Client([
    'region'  => $region,
    'version' => 'latest'
]);

// Generate unique filename
$filename = random_str() . '.' . $ext;
$key = $subFolder . $filename;

// Create command for PUT
$cmd = $s3->getCommand('PutObject', [
    'Bucket' => $bucket,
    'Key'    => $key,
    'ContentType' => $contentType  
]);

// Create pre-signed URL valid for 60 seconds
$request = $s3->createPresignedRequest($cmd, '+600 seconds');
$presignedUrl = (string) $request->getUri();

//  other function logic  

//  your read function  

    $bucket = 'your-bucket';
    $region = 'aws-region';  
    //  $filepath  as parameter  

    $s3 = new S3Client([
        'region'  => $region,
        'version' => 'latest'
    ]);

    // Create command for PUT
    $cmd = $s3->getCommand('GetObject', [
        'Bucket' => $bucket,
        'Key'    => $filepath 
    ]);

    // Create pre-signed URL valid for 60 seconds
    $request = $s3->createPresignedRequest($cmd, '+600 seconds');
    $presignedUrl = (string) $request->getUri();  
    
//  other function logic

4. php.ini Security Hardening — These php.ini changes lock down the PHP runtime by removing risk. The result is a minimal‑surface, production‑safe environment aligned with Zero Trust principles.

php.ini Setting Snippet

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Disable Dangerous Functions
; Prevent command execution, file system abuse, and code injection
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Disable URL File Access
; Prevent Remote File Inclusion (RFI) attacks
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

allow_url_fopen = Off
allow_url_include = Off

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Hide PHP Version & Reduce Fingerprinting
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

expose_php = Off

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Session Security
; Protect against hijacking, fixation, and CSRF
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = Strict
session.use_trans_sid = 0
session.sid_length = 48
session.sid_bits_per_character = 6

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Error Handling
; Never leak stack traces or internal paths to users
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = path_to_log_folder/php_errors.log

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Disable Legacy, Unsafe Features
; Prevent remote code injection via old PHP behaviors
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

register_globals = Off
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off

Security Outcome

This layered setup ensures:

Zero public exposure — no public IPs, all traffic enters through Cloudflare Tunnel only.
Authentication — JWTs are fully validated before any request is allowed to trigger the API.
No direct origin access — only Cloudflare Tunnel can reach the private API server.
No stored passwords — API connects to RDS using IAM authentication, not static credentials.
RDS Proxy only — EC2 instances cannot connect directly to the database.
Identity at every hop — IAM role → RDS Proxy → RDS.
East‑west segmentation — security groups restrict lateral movement between internal components.
Hardened runtime — PHP runs with disabled dangerous functions, strict session rules, and no version leakage.
Minimal attack surface — no file uploads, no sensitive files exposed.
Consistent Zero Trust posture — every request, device, and connection must prove identity before being allowed through.

What Next’s
This article focused on the AWS private‑network Zero Trust architecture I applied to a legacy PHP system — the part that happens inside the VPC, with no public exposure and identity‑driven access to every internal component.
In my next article, I’ll extend the story to the internet‑facing Zero Trust layer, covering how external traffic is authenticated, filtered, and isolated before it ever reaches the private network. That next piece will dive into:

Cloudflare Edge and global identity enforcement
Nginx request filtering and origin isolation
Supporting operational components like CloudWatch and the bastion host

Together, these complete the full end‑to‑end Zero Trust posture — from the public internet all the way down to the private AWS runtime.

The post Technical Deep Dive: How I Delivered Zero Trust Security for a Client’s Legacy PHP System — Without Rewrites, Downtime, or Big Costs (Part 1) appeared first on Behind the Build.

Joining the Google Cloud Get Certified Program Again — Day 1 Highlights

Jonathan Wong — Tue, 14 Apr 2026 03:01:08 +0000

I’m glad to have the chance to join the Google Cloud Get Certified Program again. Today I attended the online, live, Instructor‑Led Training (ILT) session. It was a full one‑day workshop that delivered a solid refresh across key Google Cloud services.

The training covered a wide range of topics, including:

Cloud Marketplace
VPC Networking
Google Compute Engine
Cloud Storage
Cloud SQL
Cloud Run (Kubernetes)

The session was well organized by Jellyfish Training, with clear explanations and strong demonstrations throughout the day. The structure made it easy to follow the progression from foundational services to more hands‑on deployment scenarios.

We also completed several Google Skill Boost hands‑on labs , which helped reinforce the concepts with practical exercises.

With the first stage completed, I’m looking forward to the next phase of the program — the Certification Journey. This is where the deeper preparation begins, and I’m excited to continue building momentum.

If you’re also working toward a Google Cloud certification, feel free to connect. Always open to sharing study approaches and learning together.

The post Joining the Google Cloud Get Certified Program Again — Day 1 Highlights appeared first on Behind the Build.

Building Agentic AI Solutions with Azure AI Foundry — My Training Day Review & Updated AI‑103 Study Plan

Jonathan Wong — Thu, 09 Apr 2026 17:16:00 +0000

On March 19, I attended the Microsoft Virtual Training Day: Build Agentic AI Solutions with Azure AI Foundry , a deep‑dive session focused on the emerging world of agentic AI , multi‑agent orchestration, and the evolving Azure ecosystem. With the new AI‑103 (beta) exam approaching, this training arrived at the perfect time.

Microsoft has now published the official AI‑103 syllabus and a few self‑paced modules , which provide much‑needed structure for early learners:

https://learn.microsoft.com/en-us/training/courses/ai-103t00#course-syllabus

Below is my updated summary of the training, how it aligns with the exam, and my revised learning plan.

1. Summary of the Training Day Content

The training covered the full lifecycle of building AI agents on Azure:

Getting Started with AI Agent Development on Azure

A walkthrough of Azure AI Foundry, including model catalog, prompt flow, and evaluation tools.

Developing an AI Agent with Azure AI Agent Service

How to configure, deploy, and scale agents using Microsoft’s new agent runtime.

Integrating Custom Tools into Your Agent

Connecting agents to APIs, enterprise systems, and custom tools for real‑world use cases.

Developing Agents with the Semantic Kernel SDK

Using planners, skills, connectors, and orchestration patterns to build intelligent workflows.

Orchestrating Multi‑Agent Solutions

Designing collaborative agent systems that delegate tasks and coordinate actions.

Developing Multi‑Agent Solutions with Azure AI Foundry Agent Service

Advanced multi‑agent patterns, routing strategies, and evaluation workflows.

Integrating MCP Tools with Azure AI Agents

A forward‑looking module on the Model Context Protocol (MCP) and standardized tool integration.

2. How This Training Supports AI‑103 Exam Preparation

The training aligns closely with the expected AI‑103 domains:

Azure AI Foundry fundamentals
Agent Service configuration
Semantic Kernel development
Tool integration (including MCP)
Multi‑agent orchestration
Evaluation and responsible AI

With the syllabus now available, it’s clear that AI‑103 is centered on agentic AI , not just traditional LLM operations.

3. AI‑103 Beta Exam — Registration Still Pending

Although the exam has been announced, beta registration is not yet open.

This creates a unique situation: early learners must prepare using a mix of training content, documentation, and hands‑on practice.

The newly published syllabus helps clarify the scope, but official learning paths are still limited.

4. Updated Learning Plan (Now Including Official Syllabus)

With the syllabus available, I’ve updated my study plan to align with Microsoft’s structure.

A. Follow the Official AI‑103 Syllabus

The syllabus outlines the core domains:

Azure AI Foundry
Agent development
Semantic Kernel
Tool integration
Multi‑agent orchestration
Evaluation and monitoring

This is now my primary roadmap.

B. Complete the Available Self‑Paced Modules

The course page includes a few early modules that reinforce foundational concepts.

These are short but useful for grounding terminology and workflows.

C. Deep Dive into Azure AI Foundry Documentation

Focus areas:

Model catalog
Prompt flow
Agent Service
Evaluation tools
Deployment patterns

D. Semantic Kernel GitHub Samples

Hands‑on practice with:

Planners
Skills
Connectors
Multi‑agent orchestration

E. Build Practical Mini‑Projects

To internalize the concepts, I’m building:

A multi‑agent research assistant
A tool‑calling enterprise agent
A workflow‑orchestration agent using SK

F. Review Build & Ignite Sessions

These sessions contain early previews of Microsoft’s agentic architecture.

5. Suggested Learning Plan for Other AI‑103 Candidates

If you’re also preparing for AI‑103, here’s a simple, effective path:

Start with the official syllabus
Complete the self‑paced modules
Learn Azure AI Foundry basics
Build a single agent with Azure AI Agent Service
Deep‑dive into Semantic Kernel
Create a multi‑agent solution
Practice tool integration (including MCP)
Use Azure’s evaluation tools
Monitor Microsoft Learn for new content

This sequence mirrors both the training and the exam structure.

Closing Thoughts

The March 19 training was a strong introduction to Microsoft’s agentic AI stack and a helpful starting point for AI‑103 beta preparation. With the syllabus now available, I’ve updated my study plan to align with Microsoft’s official direction.

I’ll continue sharing updates as I progress through the learning materials and as Microsoft releases more content leading up to the exam.

The post Building Agentic AI Solutions with Azure AI Foundry — My Training Day Review & Updated AI‑103 Study Plan appeared first on Behind the Build.

How I Delivered Zero Trust Security for a Client’s Legacy PHP System — Without Rewrites, Downtime, or Big Costs

Jonathan Wong — Sun, 05 Apr 2026 02:13:55 +0000

A practical playbook to implementing Zero Trust architecture using AWS and Cloudflare. Covering edge security, identity controls, and data protection for modern cloud infrastructure.

As the founder of Jonanata, I often support clients who are growing fast but whose infrastructure hasn’t kept up with modern security expectations. One recent project stands out because it reflects a challenge many founders face:

How do you bring an existing production system closer to SOC 2 and PCI‑DSS expectations , without rewriting the application, without downtime, and without blowing the budget?

My client had a public‑facing mobile app backed by a legacy PHP API server built on a proprietary framework. It worked, but it wasn’t compliant, and it wasn’t defensible. They were already using AWS and Cloudflare — but only Cloudflare’s free plan.

The constraints were clear:

No application revamp
No downtime
Free or low‑cost solutions only
Compliance‑aligned security improvements
Immediate business value

This is the story of how I delivered a Zero Trust Architecture that strengthened every layer — AWS, Cloudflare, PHP, and Nginx — while keeping the system running and the budget under control.

Why Zero Trust, SOC 2, and PCI‑DSS Matter

Before diving into the solution, it’s worth explaining these concepts in business terms.

Zero Trust Architecture (ZTA)

A modern security model built on one principle:

Never trust anything by default — verify everything.

It protects businesses from:

Credential theft
Lateral movement inside servers
Insider threats
Misconfigurations
Public exposure

For founders, Zero Trust means reduced risk , better investor confidence , and stronger customer trust.

SOC 2

A widely recognized security and operational standard.

It focuses on:

Access control
Logging and monitoring
Network restrictions
Data protection
Operational discipline

Even if you’re not formally audited, aligning with SOC 2 makes your business more trustworthy to partners and enterprise clients.

PCI‑DSS

A security standard for systems that handle payment‑related data.

It emphasizes:

Network segmentation
Least privilege
Secure coding
Logging
Encryption

Even if you don’t process payments directly, PCI‑DSS alignment reduces the risk of data breaches and strengthens your compliance posture.

The Challenge: Secure a Legacy System Without Rewriting It

The client’s PHP backend was built on a proprietary framework. Rewriting it would take months and introduce risk. Instead, I designed a solution that wraps the existing system in Zero Trust , hardens every layer, and enforces strict access control — all without touching core business logic.

The only additional cost?

CloudWatch log storage.

Everything else used AWS native features and Cloudflare’s free plan.

AWS Layer: Identity‑Based Access and Network Isolation

1. IAM Roles Only — No Stored Keys

The production EC2 instance uses a dedicated IAM role (role-ec2-production) with:

Access only to specific S3 buckets
Access only to the RDS MySQL instance
Access only to CloudWatch
All permissions scoped to resource names
No IAM users, no access keys stored on the server

Business & compliance value:

No leaked keys, no credential rotation headaches, and full alignment with SOC 2 CC6.1 and PCI‑DSS 7.1.

2. Private EC2 — No Public IP

The production EC2 sits behind a new security group (sg-ec2-production) with:

No public IP
No inbound access from the internet
Only the bastion host can reach it via private IP

Business & compliance value:

The production server is invisible to attackers.

This satisfies PCI‑DSS 1.2.1 and SOC 2 CC6.6.

3. RDS: Identity‑Based Database Access

The MySQL database:

Accepts connections only from the production SG
Uses IAM authentication (no password stored anywhere)
Generates short‑lived tokens via AWS KMS
Grants the role-ec2-production only SELECT/INSERT/UPDATE/DELETE
No public IP and is accessible only inside the VPC
Is fully encrypted

Business & compliance value:

No database passwords to leak.

No over‑privileged accounts.

Meets PCI‑DSS 3.4, 7.2 and SOC 2 CC6.1.

4. S3: Fully Private With Pre‑Signed URLs

Block all public access
Upload/download only via pre‑signed URLs

Business value:

Keeps all PII and sensitive files private and off the public internet, reducing breach risk and supporting compliance with SOC 2 (CC6.6, CC6.7, CC9.1) and PCI‑DSS (3.4, 7.1, 10.2).

5. Logging: Fluent Bit + CloudWatch + Logrotate

Logs stored outside the web root
Fluent Bit ships logs to CloudWatch
Logrotate deletes rotated logs immediately

Business & compliance value:

Centralized, tamper‑resistant logs that satisfy SOC 2 CC7.2 and PCI‑DSS 10.x.

6. Bastion Host: Controlled, Auditable Access

Only turned on when needed
Only developer IPs allowed
Developers authenticate with their own SSH keys
Developers never see the production private key
A controlled script handles access to the production EC2

Business & compliance value:

No shared credentials.

Full accountability.

Meets SOC 2 CC6.3 and PCI‑DSS 8.x.

Cloudflare Layer: Strong Perimeter Security (Free Plan)

Even on the free plan, Cloudflare provides powerful security controls when configured correctly.

1. Cloudflare Tunnel — What It Is and Why It Matters

Cloudflare Tunnel creates an outbound‑only connection from the EC2 instance to Cloudflare.

This means:

The server is never exposed to the public internet
No open ports
No public IP
All traffic passes through Cloudflare’s Zero Trust layer

Compliance value:

Supports SOC 2 CC6.6 (network segmentation) and PCI‑DSS 1.3 (no direct public access).

2. mTLS With Client Certificates

A security mechanism where both the client and server present certificates, proving their identities before any data is exchanged.

This means:

The server to trust the client
The client to trust the server
Only devices with valid client certificates can reach the API
Prevents unauthorized devices, bots, or compromised workloads from connecting to your API
Eliminates blind trust inside the network and blocks lateral movement

Business & compliance value:

Even if someone discovers the tunnel URL, or credentials (JWT) leak they cannot bypass certificate‑based authentication to access the API.

This fulfills SOC 2 CC6.7 (strong authentication) and PCI‑DSS 8.x.

3. Cloudflare Worker: JWT Validation at the Edge

Before requests reach the EC2 instance, a Worker:

Validates the JWT
Rejects invalid or expired tokens
Ensures only authenticated traffic reaches the backend

Business & compliance value:

Reduces load on the server and blocks attacks early.

Supports SOC 2 CC7.1 (input validation) and PCI‑DSS 6.5.

PHP Layer: Hardening Without Rewriting Code

Even without modifying business logic, we strengthened the runtime environment.

1. Disable Dangerous Functions

Functions like exec, system, popen, etc. are disabled. Prevents remote command execution.

2. Disable URL File Access

Prevents remote file inclusion (RFI) attacks.

3. Disable legacy PHP features that automatically turn user input into variables

Attackers can exploit old PHP behaviors such as register_globals and magic_quotes_gpc, which implicitly convert or modify user input. Prevents malicious input from becoming variables and reduces the risk of remote code injection.

4. Hide PHP Version & Disable Error Display

Prevents attackers from fingerprinting the system.

5. Session Security Hardening

Protects against session hijacking and fixation.

6. PDO Everywhere

Prevents SQL injection.

Compliance value:

Hardens the PHP runtime without modifying business logic, eliminating high‑risk attack vectors (RCE, SQL injection, session hijacking) and strengthening compliance posture for SOC 2 and PCI‑DSS by enforcing safer defaults, strict input handling, and controlled execution paths.

Nginx Layer: API‑Focused Security Controls

No directory browsing
Block multipart uploads
Enforce correct Host header
Add HSTS and minimal CSP
Limit request size
Block directory traversal
Block hidden files except .well-known
Block sensitive files
Remove version numbers

Business & compliance value:

Reduces attack surface and prevents common web vulnerabilities.

Supports PCI‑DSS 6.6 and SOC 2 CC7.1.

Defense in Depth: How Each Layer Protects the Business

How Each Layer Protects the Business

This is Zero Trust in practice : every layer assumes nothing is safe and verifies everything.

The Outcome: Compliance‑Aligned Security Without Rewrites or Cost Overruns

By applying Zero Trust principles across AWS, Cloudflare, PHP, and Nginx, we delivered:

A secure, compliant, modernized backend
No application rewrite
No downtime
No expensive tools
Only CloudWatch storage cost
A defensible security posture aligned with SOC 2 and PCI‑DSS

For the client, this meant:

Stronger trust with users
Better readiness for enterprise partnerships
Reduced operational risk
A future‑proof foundation for growth
A compliance‑aligned architecture that enables expansion into regulated or restricted markets without major rework
A security posture that meets the expectations of partners operating in highly controlled industries and jurisdictions

This is the kind of security upgrade that delivers real business value , not just technical improvements.

What’s Next

I’ll publish a deeper technical breakdown on my next AWS Builder Center article, including full configuration examples and source code in my GitHub repository.

The post How I Delivered Zero Trust Security for a Client’s Legacy PHP System — Without Rewrites, Downtime, or Big Costs appeared first on Behind the Build.

What We Learned from Building Two PartyRock Apps

Jonathan Wong — Sat, 04 Apr 2026 09:00:00 +0000

Over the past weeks, Jonanata published two exploratory articles showcasing our early experiments with AWS PartyRock — one focused on daily workflow automation, and the other on ad‑hoc research and data interpretation.

This new article serves as a conclusion and insight summary, connecting both experiments and highlighting what they reveal about practical AI adoption inside modern organizations.

Rather than revisiting the technical details, this piece focuses on the patterns, lessons, and strategic implications that emerged across both builds.

Two Experiments, One Theme: Practical AI for Everyday Work

Although the two PartyRock prototypes addressed different business needs, they shared a common purpose:

Helping people work faster with less friction.

Across both experiments, two high‑value use cases consistently stood out:

Daily Workflow Automation

Reducing repetitive tasks such as:

Drafting structured content
Summarizing updates
Generating templates
Supporting routine decision‑making

Ad‑Hoc Research & Insight Generation

Accelerating tasks like:

Quick data interpretation
Rapid content summarization
Lightweight analysis
Exploratory thinking These are universal needs across business, product, and technical teams — and they represent some of the fastest‑moving AI adoption areas today.

What These Experiments Revealed

Across both prototypes, several clear insights emerged that shape how Jonanata approaches AI strategy and implementation.

Insight 1 — No‑Code AI Is Now a Serious Prototyping Layer

PartyRock demonstrated that teams can:

Validate ideas
Test workflows
Explore user experience
Gather feedback …without writing a single line of code. This dramatically lowers the cost of experimentation and accelerates innovation cycles.

Insight 2 — Prompt Engineering Is Product Design

In both apps, the quality of the output depended entirely on:

How clearly the prompts were structured
How the workflow was sequenced
How the user inputs were framed Prompt design is no longer a technical skill — it’s a core UX skill.

Insight 3 — Small Tools Deliver Big Value

Neither prototype was complex.
Neither required infrastructure.
Neither needed custom models.
Yet both delivered immediate, practical utility.

This reinforces a key belief at Jonanata: AI value often comes from small, focused tools — not massive platforms.

Insight 4 — AI Is Most Useful When It Reduces Cognitive Load

Both apps helped users:

Think faster
Interpret information more easily
Offload repetitive mental tasks
Make decisions with less effort This is where AI shines today: reducing the mental overhead of everyday work.

Insight 5 — Prototypes Are the Bridge to Enterprise AI

PartyRock is not the final destination.

It’s the starting point.

Once a prototype proves valuable, it can evolve into:

Amazon Bedrock workflows
Lambda‑powered microservices
API‑driven applications
Secure enterprise integrations This is the path from idea → prototype → production.

Why This Matters for Jonanata’s Clients

These experiments reinforce the consulting approach we bring to organizations:

Start small
Validate quickly
Focus on real workflows
Scale only what works
Keep security and governance in mind AI adoption doesn’t need to begin with a large, multi‑year initiative. It can begin with a simple prototype that solves a real problem today. PartyRock gave us a fast, low‑risk environment to explore these ideas — and the insights gained will guide how we help clients adopt AI in a way that is:
Practical
Secure
Business‑aligned
Cost‑effective

Explore the Original Experiments

For readers who want to dive deeper, here are the two original articles:

Experiment 1 — Daily Workflow Automation

Hands‑On with AWS PartyRock: My First App and Key Takeaways – Behind the Build

Experiment 2 — Ad‑Hoc Research & Data Insights

AWS PartyRock Data App: My Second Project in the AWS AI Practitioner Challenge – Behind the Build

Closing Thoughts

These two PartyRock experiments were small by design — but they revealed big truths about how AI can support everyday business operations. As we continue expanding our AI practice, Jonanata will keep sharing insights, prototypes, and practical frameworks that help organizations adopt AI with clarity and confidence.

If your team is exploring workflow automation, research acceleration, or early AI prototyping, we’d be happy to help you shape the right path forward.

The post What We Learned from Building Two PartyRock Apps appeared first on Behind the Build.

AWS PartyRock Data App: My Second Project in the AWS AI Practitioner Challenge

Jonathan Wong — Sat, 04 Apr 2026 03:54:43 +0000

Zero Setup, No Code Data Analysis for Fast, Business Friendly Insights

As part of my AWS AI Practitioner Challenge, this is my second PartyRock project. It focused entirely on hands‑on data analysis using PartyRock’s new data app service. If you haven’t seen my first PartyRock article, check it out for details on account registration , advanced prompting , and LLM settings.

This time, we explore something even more practical: partyrock.aws/data, a lightweight, no‑code environment for ad‑hoc data analysis.

What This Project Is About

PartyRock’s data analysis feature lets you:

Upload a dataset
Ask analytical questions in natural language
Receive structured insights with generated data tables
Download the results instantly

It’s designed for business users , analysts , and operators who need quick insights without spinning up notebooks, BI tools, or ETL pipelines.

Meet Whiskers — Your Data Analyst

The workflow is intentionally simple:

Upload your CSV file directly in the chat
Ask Whiskers analytical questions about your data
Review the answer and generated data side‑by‑side
Download the generated table from the top‑right corner

This simplicity is the magic. No setup. No environment. No code.

Example: Air Quality Dataset Analysis

One of my questions was:

“How do PM10 and PM2.5 levels change throughout the day, and what explains the sharp early‑morning drop?”

Whiskers responded with:

A clear explanation of the daily pollutant pattern
A structured insight on the early‑morning drop
A generated dataset showing the hourly trend

All within seconds.

Question 1

It also handled more advanced analytical questions:

“How strongly are PM10, PM2.5, NO₂, and CO correlated during overlapping hours?”

Question 2

“What are the peak hours for each pollutant, and why do their peaks occur at different times?”

Question 3

Each answer came with supporting tables and a clean explanation.

Auto‑Generated Analysis Report

Whiskers can also prepare a well‑formatted downloadable report , including:

Summary
Key takeaways
Data tables
Insights

This is extremely useful for business teams who need quick deliverables.

Generate Analysis Report

Download Analysis Report

Why These Questions Matter

PartyRock’s real strength appears when you guide it with a clear analysis strategy , not random brainstorming. Instead of asking vague or exploratory prompts, you can frame questions around patterns , correlations , and daily cycles as the same way a human analyst approaches structured problem‑solving.

This makes PartyRock especially powerful for non‑technical users and business owners. They can focus on why a question matters, while PartyRock handles the how behind the analysis.

Here’s how strategy‑driven questions unlock value:

Strategic Question	What It Helps You Do
How do PM10 and PM2.5 levels change throughout the day?	Detect structured daily patterns instead of reacting to random noise
How strongly are PM10, PM2.5, NO₂, and CO correlated?	Understand whether pollutants share common sources or behave independently
What are the peak hours for each pollutant, and why?	Identify the drivers behind different peak times and their operational impact

By anchoring the analysis in a deliberate strategy, PartyRock becomes a flow‑maximizing tool for business users, which helping them explore data quickly, validate hypotheses, and make decisions without needing code, setup, or technical expertise.

Key Takeaways

What Works Well

Zero setup required No environment, no dependencies, no configuration.
No‑code experience Ask questions in natural language. No Python, SQL, or VBA.
Free to use Perfect for experimentation and ad‑hoc analysis.
Business‑friendly workflow Upload → Ask → Validate → Download Everything happens in one place, with data always visible.

Where It Can Improve

Simple analysis only Great for patterns, correlations, summaries. Not for complex modeling.
No real‑time in‑place data editing You can’t transform or clean data interactively.

Overall Perspective on AWS PartyRock Data Service

Whiskers bridges the gap between Ad‑hoc business analysis and Traditional BI/ETL workflows

It gives teams a fast, low‑cost, no‑setup way to explore data and validate hypotheses. The UI is significantly better than a typical chatbot because:

Data stays visible
Generated tables appear side‑by‑side
Downloads are instant
Reports are clean and structured

For daily lightweight analysis , it’s genuinely impressive.

For large‑scale, interactive, or production‑grade analytics , BI and ETL tools still remain the best choice.

The post AWS PartyRock Data App: My Second Project in the AWS AI Practitioner Challenge appeared first on Behind the Build.

Hands‑On with AWS PartyRock: My First App and Key Takeaways

Jonathan Wong — Sat, 04 Apr 2026 03:04:08 +0000

As part of the AWS AI Practitioner Challenge, I created a shareable productivity app using AWS PartyRock. In this write‑up, I walk through how I built it and share my thoughts on the platform and the overall experience.

About This App

This app helps streamline job and project applications.

You can upload your master resume and paste a job description, and the AI will automatically generate a tailored resume and cover letter. It highlights the most relevant experience and skills for the role, and you can edit the generated content directly.

App link: PartyRock | Resume and Cover Letter Tailor

How I Built My First AWS PartyRock App

Sign in to partyrock.aws . You can find the signup instructions here .
In the app build panel, you’ll find a chatbot named Whiskers , which acts as your no‑code app builder.
You describe the workflow you want, and Whiskers generates the app structure for you.

PartyRock Selected App Panel

For example, I asked Whiskers to build an app with the following workflow:

Upload a master resume
Upload additional background documents (PDF, Word, TXT)
Display uploaded file names
Allow removing uploaded files
Reuse uploaded documents within the same session
Input a job description
Generate a tailored resume and cover letter in editable text areas
Provide download buttons for both documents

Whiskers then responded with what it can build and what current limitations exist, along with alternative approaches. It generated a workable layout including:

Master resume upload
Additional documents upload
Job description input
Editable tailored resume
Editable tailored cover letter
Download buttons

The app was created in seconds. From there, I iterated with Whiskers to refine the workflow, adjust prompts, and tune the AI model settings.

App Flow Overview

App Prompt

App Model Options

Once the app was ready, I set it to “Anyone on the web” and shared the link.

App Share

Key Takeaways

What Works Well

Zero setup required No development environment or configuration is needed. Everything runs in the browser, making it friendly for non‑technical users and ideal for quick experimentation.
No‑code experience Business users can build functional AI apps without engineering support.
Free to use Low‑risk experimentation for teams exploring AI productivity tools.
Business‑friendly workflow Clear navigation from input to output, unlike a chatbot where context can be lost.
Fast app creation You can go from idea to working prototype in minutes.
Easy distribution Share a single link with colleagues or clients.
Built‑in versioning support PartyRock keeps versions of your app as you iterate. This makes it easy to experiment, roll back changes, and refine your workflow without worrying about losing previous configurations. It’s especially helpful when you’re tuning prompts or adjusting the app structure over multiple iterations.
Advanced tuning available Power users can adjust prompts and model settings for better accuracy.

Where It Can Improve

Limited file management No custom buttons for selective file removal or opt‑in/opt‑out document handling, which reduces control for business workflows.
No support for processing links PartyRock cannot read or extract information from a URL. Users must manually copy and paste website content, which slows down tasks like handling job postings or referencing online materials.
No built‑in download options You cannot export generated content as PDF or Word files, which adds manual steps to daily work.
No reset function Refreshing the page resets the entire session, which may cause loss of progress.
Inconsistent guidance from Whiskers Whiskers sometimes provides instructions for features that do not exist. For example, it initially told me to download a .docx file from a widget menu, then later corrected itself and said PartyRock does not support downloads. This can confuse users and lead to unnecessary redesign of the workflow.

Overall Perspective on AWS PartyRock

AWS PartyRock is a strong entry‑level no-code platform for rapid AI prototyping. In my case, it took about 20 minutes to build and share a fully working app, which makes it ideal for quick experimentation and early validation of ideas.

It allows users to explore AI‑assisted workflows, test concepts, and understand how AI can enhance productivity without requiring engineering resources or technical setup. The no‑code interface, zero environment configuration, and built‑in versioning make it easy to iterate and refine ideas quickly.

PartyRock is designed for fast learning cycles and creative exploration. It provides a simple way to try out new AI‑driven workflows before deciding whether to develop a more advanced or customized solution later on.

The post Hands‑On with AWS PartyRock: My First App and Key Takeaways appeared first on Behind the Build.