Siri ini cover Cloud Security Engineering dari sudut pandang 2026 — role yang dah berubah, skill baru yang mandatory, tooling landscape, dan cara cloud security engineer navigate dunia yang dah converge dengan AI dan agentic systems.

Nota dalam Bahasa Melayu untuk sesiapa yang nak masuk atau dah dalam bidang cloud security dan nak tahu apa yang sebenarnya berubah sekarang.

Pendahuluan

Ada satu quote dari CSOH.org yang kena dengan betul:

“Cloud Security Engineer is the connective tissue that turns ten specialists’ work into one coherent security posture.”

Kau bukan specialist dalam satu benda. Kau adalah orang yang sambung semua benda.

Tapi “semua benda” tu dah berubah dengan cepat. Skill yang cukup untuk masuk bidang ni tahun 2023 tak cukup lagi untuk tahun 2026 — bukan sebab kau tak belajar, tapi sebab landscape dah shift secara structural.

Post ni breakdown jujur: apa yang sama, apa yang berubah, dan apa yang baru sama sekali.

Apa yang masih sama (jangan skip)

Sebelum cakap pasal benda baru, kena jelas dulu: foundation masih sama. Orang yang skip benda ni sebab nak terus ke AI/agentic stuff akan struggle.

Foundation yang masih wajib:

Kalau kau lemah dalam mana-mana di atas — fix itu dulu sebelum belajar benda lain.

Apa yang berubah (2024 → 2026)

1. Identity jadi lebih kompleks — bukan setakat manusia lagi

Dulu IAM = manage user dan service accounts.

Sekarang kau kena manage:

• Human identity — MFA, SSO, conditional access
• Workload identity — SPIFFE/SPIRE, pod service accounts, instance profiles
• Agent identity — AI agent pun ada identity. Manifest declaration, capability token, audit binding
• Non-human identity (NHI) — API keys, OAuth tokens, CI/CD service accounts — sekarang dah ada dedicated tooling: Aembit, Indent, Strata

# SPIFFE workload identity example
# setiap workload dapat SVID (SPIFFE Verifiable Identity Document)
# bukan hardcoded credential lagi

spiffe://trust-domain/ns/production/sa/security-auditor

Apa kena belajar: SPIFFE/SPIRE documentation, cloud provider workload identity (AWS IRSA, GCP Workload Identity Federation, Azure Managed Identity).

2. Supply chain security jadi mandatory

Post-xz-utils backdoor (2024), Log4Shell (2021), SolarWinds (2020) — sekarang supply chain attack dah jadi standard attack vector, bukan edge case.

Benda baru yang kena faham:

• SBOM (Software Bill of Materials) — inventory semua dependency kau. EU Cyber Resilience Act mewajibkan SBOM untuk software yang dijual di EU.
• SLSA framework (Supply chain Levels for Software Artifacts) — provenance verification dari source ke build ke deploy
• Sigstore/Cosign — sign dan verify container images secara kriptografik

# Verify container image signature
cosign verify \
  --certificate-identity="https://github.com/actions/..." \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  myapp:latest

Tools:

• Trivy — SCA + container scan + secret detection (semua dalam satu)
• Grype — vulnerability scanner untuk SBOM
• Syft — generate SBOM dari container/filesystem
• Renovate/Dependabot — automated dependency update

3. Runtime security dah jadi mainstream

Dulu runtime security = mahal, complicated, edge case untuk high-security environment.

Sekarang dengan eBPF, runtime security boleh deploy ke semua orang tanpa kernel module atau agent yang heavy.

# Falco rule example — detect unexpected network connection dari container
- rule: Unexpected outbound connection
  desc: Container buat outbound connection ke IP yang tak dalam allowlist
  condition: >
    outbound and container and
    not proc.name in (known_processes) and
    not fd.sip in (allowed_ips)
  output: >
    Unexpected connection (user=%user.name container=%container.name
    ip=%fd.sip port=%fd.sport)
  priority: WARNING

Tools yang kena tahu:

• Falco — runtime threat detection, Kubernetes-native
• Tetragon (Cilium) — eBPF-based enforcement, bukan sekadar detect tapi boleh enforce
• KubeArmor — security policy enforcement untuk Kubernetes workloads

Kenapa penting sekarang: Container escape attacks makin sophisticated. Dengan agent yang boleh run arbitrary code, runtime detection jadi safety net yang penting.

4. IaC security dah jadi pre-commit, bukan post-deploy

Dulu security scan IaC berlaku bila ada audit atau before production. Sekarang ia berlaku sebelum kau push code.

1
repos:
2
  - repo: https://github.com/bridgecrewio/checkov
3
    rev: 3.2.0
4
    hooks:
5
      - id: checkov
6
        args: [--framework, terraform]
7

8
  - repo: https://github.com/aquasecurity/tfsec
9
    rev: v1.28.0
10
    hooks:
11
      - id: tfsec

Policy-as-code (OPA/Rego) — kau tulis policy dalam code, enforce dalam CI/CD:

1
# Rego policy — block S3 bucket yang public
2
deny[msg] {
3
    resource := input.resource.aws_s3_bucket[name]
4
    resource.acl == "public-read"
5
    msg := sprintf("S3 bucket '%v' kena private", [name])
6
}

Shift ini bermaksud: Security engineer sekarang kena comfortable dengan developer tools — git hooks, CI/CD pipelines, PR review process.

5. AI-augmented security — bukan pilihan, dah jadi standard

Gartner predict 50% SOC akan ada AI decision support by end 2026. Prediction tu sekarang dah jadi operational reality.

Benda konkrit yang dah berlaku:

• AI-assisted alert triage — agent review alert, classify severity, suggest response, escalate yang perlu human judgment sahaja
• AI-generated detection rules — “describe the behavior” → agent generate Sigma rule / KQL query
• Natural language threat hunting — “show me all EC2 instances that made outbound connections to unknown IPs in the last 24 hours” → auto-translate ke query
• Automated remediation — agent detect misconfigured S3 bucket, generate PR untuk fix, tunggu human approval sebelum apply

Apa kena belajar sekarang:

• Cara validate AI-generated detection rules (bukan blind trust)
• Cara tune AI alert classifier untuk reduce false positive
• Cara design human-in-the-loop workflow untuk automated remediation
• OWASP Top 10 for LLM Applications (sebab kau akan secure AI tools juga)

6. Agentic AI security — skill baru yang genuine

Ini yang paling baru dan paling ramai yang belum prepare.

December 2025: OWASP publish Top 10 for Agentic Applications — first formal taxonomy untuk autonomous AI agent risks. Ini bukan extension dari LLM Top 10 biasa — ini kategori risiko baru:

• Goal hijacking, tool misuse, identity abuse, memory poisoning
• Cascading failures, rogue agents, data exfiltration via reasoning
• Privilege escalation, insecure tool chaining, audit evasion

Cloud Security Engineer 2026 kena tahu:

1. Macam mana nak threat model agent system (bukan cuma application threat model)
2. Macam mana nak design least-privilege Manifest untuk agent
3. Macam mana nak setup agent observability (Langfuse, OpenTelemetry)
4. Macam mana nak review agent Manifest sebelum production deploy (sama macam code review)
5. AEGIS Framework (Forrester) — governance framework untuk enterprise agentic AI deployment

Role yang muncul dari semua perubahan ni

Dari breadth role cloud security engineer, sekarang ada beberapa specialization yang muncul:

Realist take: Untuk entry-level, kau masuk sebagai generalist. Specialization datang dengan experience. Tapi kau kena aware tentang semua specialization ni supaya boleh communicate dan collaborate dengan specialist.

Roadmap konkrit: dari sekarang ke 12 bulan

Bulan 1-3: Foundation + modern tooling

• AWS/Azure fundamentals — minimum 1 cloud platform sampai operational depth
• Checkov + Trivy daily use — scan code repo kau sendiri
• Falco setup kat local Kubernetes (minikube/kind)
• Baca OWASP Top 10 for LLM Applications + Agentic Applications

Bulan 4-6: Intermediate + automation

• Tulis satu OPA/Rego policy dari scratch
• Setup pre-commit hooks dengan security scan dalam satu project
• Cuba SPIFFE/SPIRE locally — faham workload identity flow
• SBOM generation dengan Syft, scan dengan Grype

Bulan 7-9: Advanced + AI security

• Setup NeMo Guardrails untuk satu LLM application
• Implement agent Manifest + Agent Governance Toolkit dalam satu project
• Setup Langfuse untuk trace agent behavior
• Baca Microsoft Agent Governance Toolkit documentation + try it

Bulan 10-12: Portfolio + specialization

• Bina satu complete “secure agent” project — dari threat model, Manifest, guardrails, sampai observability
• Join satu CTF yang ada cloud/AI security category (CloudGoat, HackTheBox Cloud)
• Contribute ke salah satu open source security tool (Falco, Checkov, Guardrails AI)
• Tulis tentang apa yang kau belajar — blog, LinkedIn, apa-apa je

Penutup

Role cloud security engineer sekarang adalah role yang lebar tapi kena ada depth sekurang-kurangnya dalam satu area.

Orang yang survive dalam field ni adalah orang yang treat breadth sebagai strength — connector yang faham macam mana IAM, runtime security, supply chain, dan sekarang AI security connect dengan satu sama lain.

Bukan expert dalam semua. Tapi faham semua cukup untuk buat keputusan yang betul bila dua domain overlap — dan dalam 2026, semua domain overlap dengan AI.

Rujukan:

• CSOH.org — Cloud Security Engineer: The Role in Depth
• Scaler — Cloud Security Engineer Roadmap 2026
• Datacipher — 10 Cloud Security Skills That Set IT Professionals Apart in 2026
• Refonte Learning — Cloud Security Engineering in 2026: 5 Trends
• Microsoft — Secure Agentic AI End-to-End (RSAC 2026)
• OWASP Top 10 for Agentic Applications (Dec 2025)
• Forrester AEGIS Framework for Agentic AI (2026)
• SLSA Framework — Supply Chain Levels for Software Artifacts

Nota lapangan dalam Bahasa Melayu. Untuk Cloud Security Engineer yang nak faham hubungan antara Cloud Security Baseline, CSPM, dan cara enforce posture secara automated.

Pendahuluan

Ada satu pattern yang berlaku hampir setiap kali organisasi kena breach melalui cloud:

Bukan exploit zero-day. Bukan nation-state attacker dengan tools sophisticated. Konfigurasi default yang tak pernah ditukar.

Root account tanpa MFA. S3 bucket yang public by default. CloudTrail yang disabled. Security group yang allow 0.0.0.0/0. Semua ni wujud sebab cloud provider set default yang convenient untuk onboarding — bukan default yang secure.

Cloud Security Baseline (CSB) adalah jawapan kepada masalah ini: satu set kontrol minimum yang kena ada dari hari pertama, sebelum workload pertama deploy.

Apa itu Cloud Security Baseline?

Cloud Security Baseline = set kontrol security yang kena enforce di setiap account/subscription/project, tanpa exception, sebelum mana-mana workload dibenarkan run.

Bezanya dengan security hardening biasa:

1
Security Hardening:         Cloud Security Baseline:
2
- Per-workload               - Per-account/subscription
3
- Selepas deploy             - Sebelum workload pertama
4
- Specific to service        - Universal untuk semua resource
5
- Optional (best practice)   - Mandatory (non-negotiable floor)

CSPM vs CSB:

1
Cloud Security Baseline          Cloud Security Posture Management
2
(CSB)                            (CSPM)
3
─────────────────────────        ────────────────────────────────
4
STATIC definition                CONTINUOUS monitoring
5
"Apa yang MESTI ada"             "Adakah ia masih ada?"
6
Setup sekali, enforce always     Scan berulang, alert bila drift
7
Foundation / floor               Ongoing visibility
8
Checklist + policy-as-code       Tool (Wiz, Defender, Orca...)

CSB adalah apa yang kau define. CSPM adalah tool yang pastikan CSB tu masih dalam keadaan baik.

Benchmark yang jadi asas CSB

Kau tak perlu cipta CSB dari kosong. Ada benchmark established yang boleh jadi starting point:

CIS Benchmarks (paling widely-used)

AWS Security Hub sekarang support CIS AWS Foundations Benchmark v5.0 (announced Oct 2025) — boleh enable terus dari console, auto-scan setiap resource.

Microsoft Cloud Security Benchmark (MCSB)

Microsoft publish MCSB yang cover multi-cloud (AWS + Azure dalam satu framework). Bahagian “Posture and Vulnerability Management” dalam MCSB secara explicit define:

“Define the security configuration baselines for different resource types in the cloud. Use configuration management tools to establish the configuration baseline automatically before or during resource provisioning.”

NIST SP 800-53 Rev 5

Untuk regulated industries (government, healthcare, finance) — NIST controls jadi mandatory. Boleh map CIS controls ke NIST untuk dual compliance.

CSB Minimum — Apa kena ada di setiap account

Ini floor yang tidak boleh dikompromikan — berdasarkan CIS AWS v7.0 + MCSB + field experience:

1. Identity & Access (IAM)

1
✅ Root account MFA enabled
2
✅ Root account access keys DELETED (bukan disabled, deleted)
3
✅ MFA required untuk semua human users
4
✅ Password policy: min 14 chars, complexity, no reuse 24x
5
✅ Tiada inline policies (semua managed policies)
6
✅ Principle of least privilege enforced
7
✅ No wildcard (*) dalam Action atau Resource untuk production roles
8
✅ Access keys rotate setiap 90 hari
9
✅ Inactive users/roles disabled selepas 90 hari

2. Logging & Monitoring

1
✅ CloudTrail enabled — ALL regions, ALL management events
2
✅ CloudTrail log file validation enabled
3
✅ CloudTrail logs dihantar ke S3 + CloudWatch Logs
4
✅ S3 bucket untuk CloudTrail: private, versioning on, MFA delete
5
✅ VPC Flow Logs enabled untuk semua VPC
6
✅ Config Rules enabled (AWS Config)
7
✅ GuardDuty enabled semua region
8
✅ Security Hub enabled + CIS benchmark enabled

3. Networking

1
✅ Tiada Security Group dengan inbound 0.0.0.0/0 ke port 22 (SSH)
2
✅ Tiada Security Group dengan inbound 0.0.0.0/0 ke port 3389 (RDP)
3
✅ Default VPC tidak digunakan untuk production workload
4
✅ VPC endpoints untuk S3 dan DynamoDB (elak traffic keluar internet)
5
✅ Network ACLs reviewed, no allow-all rules

4. Storage & Data

1
✅ S3 Block Public Access enabled — account level
2
✅ S3 bucket versioning enabled untuk critical data
3
✅ EBS encryption by default enabled
4
✅ RDS encryption at rest enabled
5
✅ S3 Server-Side Encryption (SSE-S3 minimum, SSE-KMS untuk sensitive)
6
✅ Secrets dalam Secrets Manager / Parameter Store, bukan plaintext

5. Billing & Governance

1
✅ Billing alerts configured (threshold bukan nombor besar)
2
✅ Budget alerts configured
3
✅ Cost anomaly detection enabled
4
✅ Resource tagging policy enforced (Owner, Environment, CostCenter)
5
✅ AWS Organizations SCPs (Service Control Policies) untuk restrict regions

Cara enforce CSB secara automated

Manual checklist tak sustainable. Ini cara buat CSB enforce itself:

Option 1: AWS Config Rules (built-in, free tier ada)

1
# Terraform — deploy CIS-aligned Config Rules
2
resource "aws_config_config_rule" "mfa_enabled_for_iam_console" {
3
  name = "mfa-enabled-for-iam-console-access"
4

5
  source {
6
    owner             = "AWS"
7
    source_identifier = "MFA_ENABLED_FOR_IAM_CONSOLE_ACCESS"
8
  }
9
}
10

11
resource "aws_config_config_rule" "root_mfa_enabled" {
12
  name = "root-account-mfa-enabled"
13

14
  source {
15
    owner             = "AWS"
16
    source_identifier = "ROOT_ACCOUNT_MFA_ENABLED"
17
  }
18
}
19

20
resource "aws_config_config_rule" "s3_block_public" {
21
  name = "s3-account-level-public-access-blocks"
22

23
  source {
24
    owner             = "AWS"
25
    source_identifier = "S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS"
26
  }
27
}

Option 2: OPA/Rego Policy-as-Code

1
# csb_baseline.rego — enforce CSB dalam CI/CD pipeline
2
package csb.baseline
3

4
# DENY: S3 bucket yang ada public access
5
deny[msg] {
6
    resource := input.resource.aws_s3_bucket[name]
7
    resource.acl == "public-read"
8
    msg := sprintf("CSB VIOLATION: S3 bucket '%v' kena private", [name])
9
}
10

11
# DENY: Security group yang allow SSH dari mana-mana
12
deny[msg] {
13
    resource := input.resource.aws_security_group[name]
14
    rule := resource.ingress[_]
15
    rule.from_port <= 22
16
    rule.to_port >= 22
17
    rule.cidr_blocks[_] == "0.0.0.0/0"
18
    msg := sprintf("CSB VIOLATION: Security group '%v' allow SSH dari 0.0.0.0/0", [name])
19
}
20

21
# DENY: IAM user tanpa MFA
22
deny[msg] {
23
    resource := input.resource.aws_iam_user[name]
24
    not resource.force_destroy
25
    not input.resource.aws_iam_user_login_profile[name]
26
    msg := sprintf("CSB VIOLATION: IAM user '%v' tiada MFA configured", [name])
27
}

Option 3: Checkov pre-commit (paling senang untuk start)

1
repos:
2
  - repo: https://github.com/bridgecrewio/checkov
3
    rev: 3.2.0
4
    hooks:
5
      - id: checkov
6
        args:
7
          - --framework
8
          - terraform
9
          - --check
10
          - CKV_AWS_1    # S3 bucket access logging
11
          - CKV_AWS_8    # EC2 no public IP
12
          - CKV_AWS_18   # S3 no public access
13
          - CKV_AWS_41   # CloudTrail enabled
14
          - --soft-fail  # warn dulu, tukar ke hard-fail bila ready

Drift Detection — CSPM untuk pantau CSB

CSB define baseline. Drift berlaku bila seseorang atau sesuatu tukar konfigurasi dari baseline tu. CSPM tool pantau drift ini secara real-time.

Cara drift berlaku

1
Time 0:  S3 bucket — private ✅ (CSB compliant)
2
Time 1:  Developer silap set ACL → public-read ← DRIFT EVENT
3
Time 2:  CSPM detect within 5 min → alert
4
Time 3:  Auto-remediation atau manual fix
5
Time 4:  S3 bucket — private ✅ (compliant semula)

Tanpa CSPM, drift mungkin tak dikesan selama berhari-hari atau berminggu-minggu.

Tool untuk drift detection 2026

Untuk small team / startup: AWS Config + Checkov dalam CI/CD sudah cukup untuk CSB enforcement. Free, automated, dan coverage untuk 80% common misconfigs.

Untuk enterprise: Wiz atau Orca untuk visibility luas, Defender untuk Azure-native, tfdrift-falco untuk real-time IaC drift.

CSB dan AI/Agentic workloads — gap baru 2026

CSB tradisional (CIS, NIST) tak cover AI/agent workloads. Ini gap yang semakin kritikal:

CSB extension untuk AI workloads (praktik terbaik sekarang):

1
ai_baseline:
2
  agent_identity:
3
    - setiap agent ada dedicated IAM role (bukan shared)
4
    - role tak boleh assume human user roles
5
    - session duration maximum 1 jam
6
  audit:
7
    - setiap agent action kena ada task_id dalam log
8
    - CloudTrail + Langfuse/OTel untuk full trace
9
  network:
10
    - agent roles dalam SCP — restrict ke allowed API endpoints
11
    - egress filter via VPC endpoint policy
12
  data_access:
13
    - agent tak boleh access production data tanpa explicit tag approval
14
    - S3 bucket policy: deny jika tag "ai-approved" tidak ada

Workflow praktis: setup CSB dari kosong

Untuk account baru atau audit existing account:

1
Minggu 1: Assess
2
  → Run Checkov scan atas Terraform state
3
  → Enable AWS Security Hub + CIS benchmark
4
  → Generate baseline gap report
5

6
Minggu 2: Fix critical (Severity HIGH+)
7
  → Root MFA, no public S3, CloudTrail all regions
8
  → Delete unused access keys
9
  → Fix open SSH/RDP security groups
10

11
Minggu 3: Automate enforcement
12
  → Terraform untuk Config Rules
13
  → OPA/Rego policies dalam CI/CD
14
  → Pre-commit Checkov hooks
15

16
Minggu 4+: Continuous
17
  → CSPM tool (minimum: AWS Config + Security Hub)
18
  → Alert routing ke Slack/PagerDuty
19
  → Monthly CSB review dan update

Penutup

CSB adalah security floor, bukan ceiling.

Kau boleh ada CSB yang perfect dan masih kena breach — kalau attacker exploit application layer, insecure code, atau zero-day. Tapi CSB memastikan kau tak kena breach kerana sebab-sebab yang boleh dielak: root tanpa MFA, S3 yang accidental public, CloudTrail yang off.

Dalam dunia cloud yang besar dan cepat berubah, CSB yang automated dan CSPM yang continuous adalah minimum viable security posture. Bukan optional. Bukan “nak buat nanti”. Dari hari pertama account wujud.

Rujukan:

• CIS AWS Foundations Benchmark v7.0.0 — Tenable Audits (Apr 2026)
• CIS Azure Foundations Benchmark v6.0.0 — NIST NCP (Apr 2026)
• AWS Security Hub — CIS AWS Foundations Benchmark v5.0 support (Oct 2025)
• Microsoft Cloud Security Benchmark — Posture and Vulnerability Management
• ISACA — Cloud Security Posture Management: Control Plane for Modern Cloud Risk (2026)
• CloudToolStack — Cloud Security Baseline 2026: What Every Account Should Have
• higakikeita/tfdrift-falco — Real-time Terraform Drift Detection via Falco (2026)
• OpenMalo — CSPM Practical Guide 2026