انجینئرز کے لیے مکمل SOC 2 قسم II عمل درآمد ہینڈ بک: عملی احکامات کے ساتھ ایک ماہانہ روڈ میپ

از /

اگر آپ کی ٹیم SOC 2 قسم II کے جائزے کی تیاری کر رہی ہے، تو یہ ہینڈ بک آپ کے لیے ہے۔ عین مطابق 90 دن کی ٹائم لائن، 14 کلیدی کنٹرولز، اور شواہد اکٹھا کرنے کے بنیادی ڈھانچے کے لیے ایک خود ساختہ گائیڈ جسے آڈیٹرز حقیقت میں دیکھتے ہیں۔

ہر کوئی کنٹرول لسٹ شائع کرتا ہے۔ لیکن کوئی بھی ہفتہ وار انجینئرنگ کیلنڈر شائع نہیں کرتا ہے تاکہ یہ یقینی بنایا جا سکے کہ چیزیں ٹریک پر رہیں۔

یہاں 90 دن کی صحیح ٹائم لائن ہے، بشمول وہ غلطیاں جو 60 دن کا اضافہ کرتی ہیں اور ان سے کیسے بچنا ہے۔

انڈیکس

  1. جو آپ سیکھیں گے۔

  2. شرطیں

  3. ہفتے 1-2: دائرہ کار کا تعین کریں۔

  4. ہفتے 3-6: 14 کنٹرولز جنہیں پہلے دن کو چالو کیا جانا چاہیے۔

  5. ہفتے 7-10: ثبوت جمع کرنے کا بنیادی ڈھانچہ

  6. 11-14 ہفتے: آڈیٹر کا انتخاب اور تیاری کا اندازہ

  7. 15-18 ہفتے: مشاہدے کی مدت

  8. 90 دن SOC2 ٹائم لائن کا خلاصہ

  9. آگے کیا ہے

  10. وسائل

جو آپ سیکھیں گے۔

اس گائیڈ کے اختتام تک، آپ کو معلوم ہو جائے گا:

  • SOC2 حدود کا صحیح طریقے سے دائرہ کار کیسے کریں – وہ فیصلہ جو ہر چیز کا تعین کرتا ہے

  • 14 کنٹرول جو مشاہدے کی مدت کے 1 دن کو چالو کرنا ضروری ہے۔

  • ثبوت جمع کرنے کا انفراسٹرکچر کیسے بنایا جائے جو خود بخود چلتا ہے۔

  • آڈیٹرز کا انتخاب کیسے کریں اور تیاری کا اندازہ کیسے چلائیں۔

  • مشاہدے کی مدت کے دوران کیا ہوتا ہے اور گھڑی کو دوبارہ شروع کیے بغیر وقفہ کو کیسے کم کیا جائے۔

آئیے اندر غوطہ لگاتے ہیں۔

شرطیں

پیروی کرنے سے پہلے، آپ کو ضرورت ہو گی:

علم:

  • AWS خدمات کی بنیادی تفہیم (EC2, RDS, S3, IAM, VPC)

  • کوڈ ٹولز کے طور پر Terraform یا دیگر انفراسٹرکچر کا علم۔

  • GitHub ایکشنز YAML ورک فلوز کو پڑھنا آسان ہے۔

  • SOC2 کیا ہے اس کے بارے میں ایک عام فہم — اگر آپ شروع سے شروع کر رہے ہیں، تو پہلے AICPA کا SOC2 جائزہ پڑھیں۔

اوزار اور رسائی:

  • ایڈمنسٹریٹر کی رسائی کے ساتھ AWS اکاؤنٹ

  • ایڈمنسٹریٹر کے مراعات کے ساتھ GitHub تنظیم

  • ٹیرافارم انسٹال ہوا (v1.0 یا اس سے زیادہ)

  • Python 3.8 یا اس سے زیادہ (Evidence Collector Lambda کے لیے)

  • تعمیل آٹومیشن پلیٹ فارم (وانٹا یا ڈراٹا) آپ کے AWS اکاؤنٹ اور GitHub تنظیم سے منسلک ہے

تخمینی وقت: یہ شروع سے ختم ہونے تک 90 دن تک رہتا ہے، پہلے 6 ہفتوں کے لیے فی ہفتہ تقریباً 8-12 گھنٹے فعال انجینئرنگ کے کام کے ساتھ، مشاہدے کی مدت کے دوران 2-4 گھنٹے فی ہفتہ تک کم ہو جاتا ہے۔

ہفتے 1-2: دائرہ کار کا تعین کریں – SOC2 کی حدود میں اور باہر

زیادہ تر ٹیمیں کیا غلط کرتی ہیں۔

زیادہ تر ٹیمیں اپنی SOC2 کی حدود کو بہت وسیع کرتی ہیں۔ اس میں تمام AWS اکاؤنٹس، تمام خدمات، اور تمام ماحول شامل ہیں۔ یہ ایک غلطی ہے۔ صحیح وجہ درج ذیل ہے:

وسیع تر دائرہ کار کا مطلب ہے کہ لاگو کرنے کے لیے مزید کنٹرول، جمع کرنے کے لیے مزید ثبوت، اور آڈیٹرز کے لیے جانچ کے لیے مزید نظام موجود ہیں۔

فریم کے اندر تمام سسٹمز کو تمام 14 کنٹرولز کو پورا کرنا چاہیے۔ ڈیولپمنٹ سینڈ باکس کو شامل کرنے کا مطلب یہ ہے کہ انجینئر کے لیب کے ماحول میں گارڈ ڈیوٹی کا فعال ہونا اور CloudTrail لاگنگ اور برانچ پروٹیکشن تعینات ہونا ضروری ہے۔ یہ ایک ایسے نظام کے لیے ہفتوں کے کام اور مہینوں کے شواہد اکٹھا کرتا ہے جس سے گاہک کو کوئی خطرہ نہیں ہوتا۔

مناسب طور پر محدود دائرہ کار کا مطلب یہ ہے کہ اس میں صرف وہ سسٹم شامل ہیں جو کسٹمر کے ڈیٹا کو اسٹور، پروسیس یا منتقل کرتے ہیں اور یہ ثابت کرتے ہیں کہ ان سسٹمز تک کوئی اور چیز نہیں پہنچ سکتی۔

غلط رینج (زیادہ شامل):

Entire AWS Organization
├── Production (in scope)
├── Staging (in scope)
├── Development (in scope)
├── Sandbox (in scope)
└── CI/CD (in scope)

اچھی رینج (مناسب حد تک محدود):

SOC2 Boundary
├── Production AWS Account (in scope)
├── Production EKS Cluster (in scope)
├── Production RDS (in scope)
└── Everything else (OUT of scope — proven by network segmentation)

مناسب طریقے سے محدود دائرہ کار کام کرتا ہے کیونکہ یہ ان سسٹمز کے گرد دفاع کی سخت ترین لائن کھینچتا ہے جو دراصل کسٹمر کے ڈیٹا پر کارروائی کرتے ہیں۔ اس لائن سے باہر کی کوئی بھی چیز خارج ہے۔ ایک مفروضے کے بجائے، نظام کو تکنیکی کنٹرول سے خارج کر دیا جاتا ہے جو اسے حدود کے اندر کسی بھی چیز تک پہنچنے سے روکتے ہیں۔

اسکوپنگ فریم ورک

اپنے بنیادی ڈھانچے کے ہر نظام کے بارے میں یہ چار سوالات پوچھیں:

سوال پھر اگر نہیں
کیا یہ سسٹم کسٹمر ڈیٹا کو اسٹور، پروسیس یا ٹرانسمٹ کرتے ہیں؟ حد کے اندر دائرہ کار سے باہر
کیا یہ نظام صارفین کو درپیش خدمات کی دستیابی کو متاثر کرے گا؟ حد کے اندر دائرہ کار سے باہر
کیا اس نظام کو پیداواری اسناد تک رسائی حاصل ہے؟ حد کے اندر دائرہ کار سے باہر
کیا اس سسٹم سے سمجھوتہ کیا جا سکتا ہے جس کے نتیجے میں کسٹمر ڈیٹا کی خلاف ورزی ہو سکتی ہے؟ حد کے اندر دائرہ کار سے باہر

کوئی بھی نظام جہاں صرف ایک سوال کا جواب ہاں میں ہو وہ آپ کی حدود میں ہے۔

نیٹ ورک سیگمنٹیشن – تکنیکی ثبوت جو دائرہ برقرار رکھتا ہے۔

نیٹ ورک سیگمنٹیشن آپ کے انفراسٹرکچر کو الگ تھلگ علاقوں میں تقسیم کرنے کا عمل ہے تاکہ ایک علاقے کے سسٹمز دوسرے علاقے کے سسٹمز کے ساتھ بات چیت نہ کر سکیں جب تک کہ واضح طور پر اجازت نہ ہو۔

SOC2 کے تناظر میں، یہ تکنیکی کنٹرولز ہیں جو پالیسی کے ساتھ ساتھ بنیادی ڈھانچے کے نفاذ کے ذریعے ظاہر کرتے ہیں کہ دائرہ کار سے باہر کے نظام جسمانی طور پر دائرہ کار کے نظام تک نہیں پہنچ سکتے۔

نیٹ ورک کی تقسیم کے بغیر، SOC2 آڈیٹرز اس بات پر بھروسہ نہیں کر سکتے کہ آپ کا دائرہ حقیقی ہے۔ سینڈ باکس ماحول میں ایک ڈویلپر جو پروڈکشن ڈیٹا بیس سے استفسار کر سکتا ہے اس کا مطلب ہے کہ سینڈ باکس مؤثر طریقے سے دائرہ کار میں ہے، قطع نظر اس کے کہ خاکہ کیا کہتا ہے۔

ٹیرافارم پروڈکشن اور غیر پیداواری ماحول کے درمیان نیٹ ورک کی تقسیم کو لاگو کرتا ہے: نیٹ ورک ایکسیس کنٹرول لسٹ (NACL) وسیع نجی IP رینج (10.0.0.0/8) سے لے کر پروڈکشن VPC تک تمام ان باؤنڈ ٹریفک کو رینج کے اندر روکتی ہے۔ aws_vpc_peering_connection تبصرے ہم مرتبہ کے ماحول کے بارے میں جان بوجھ کر کیے گئے فیصلوں کی دستاویز نہیں کرتے ہیں۔

# This account has NO VPC peering to non-production environments.
# The absence of peering is itself the segmentation control.
# Do NOT add peering connections to this account without SOC2 scope review.

resource "aws_network_acl" "deny_non_production" {
  vpc_id = aws_vpc.production.id

  # Block all inbound traffic from non-production IP ranges
  ingress {
    rule_no    = 100
    action     = "deny"
    from_port  = 0
    to_port    = 0
    protocol   = "-1"
    cidr_block = "10.0.0.0/8"
  }

  # Allow legitimate inbound traffic (HTTPS from internet)
  ingress {
    rule_no    = 200
    action     = "allow"
    from_port  = 443
    to_port    = 443
    protocol   = "tcp"
    cidr_block = "0.0.0.0/0"
  }

  # Allow all outbound (tighten this per your architecture)
  egress {
    rule_no    = 100
    action     = "allow"
    from_port  = 0
    to_port    = 0
    protocol   = "-1"
    cidr_block = "0.0.0.0/0"
  }

  tags = {
    Name        = "production-nacl"
    Environment = "production"
    Purpose     = "SOC2 network segmentation"
  }
}

Terraform لاگو کرنے کے بعد، مندرجہ ذیل کمانڈ کے ساتھ تقسیم کی تصدیق کریں:

# Confirm no VPC peering connections exist from production to non-production
aws ec2 describe-vpc-peering-connections 
  --filters Name=status-code,Values=active 
  --query 'VpcPeeringConnections[*].{ID:VpcPeeringConnectionId,Requester:RequesterVpcInfo.VpcId,Accepter:AccepterVpcInfo.VpcId}' 
  --output table

ڈیلیوری قابل: SOC2 باؤنڈری ڈایاگرام

ہفتہ 1 یا 2 کے آخر تک، آپ کو ایک باؤنڈری ڈایاگرام، ایک بصری دستاویز کی ضرورت ہوگی جو تمام دائرہ کار کے نظام، تمام دائرہ کار سے باہر کے نظام، اور ان کے درمیان تقسیم کنٹرول کو دکھائے۔

یہاں آپ کے خاکہ میں کیا شامل ہونا چاہئے:

تمام AWS سروسز، تمام ڈیٹا فلو ایرو، اور گرینولر کنٹرول لیبلز شامل ہیں۔ یہ خاکہ کلیدی دائرہ کار کے ثبوت کے طور پر کام کرتا ہے اور عام طور پر آڈیٹر کی درخواست کی پہلی چیز ہوتی ہے۔

ہفتے 3-6: 14 کنٹرولز جنہیں پہلے دن کو چالو کیا جانا چاہیے۔

آپ کو ان 14 کنٹرولز کو نافذ کرنا چاہیے اور مشاہدے کی مدت کے پہلے دن سے شروع ہونے والے شواہد کو فعال طور پر جمع کرنا چاہیے۔ دیر سے اضافہ اس کنٹرول کے لیے مشاہداتی مدت کی گھڑی کو آڈٹ کی مدت کے پہلے دن کے بجائے نفاذ کی تاریخ سے دوبارہ شروع کرنے کا سبب بنتا ہے۔

مشاہدے کی مدت کے بارے میں سوچیں کہ آپ کے بنیادی ڈھانچے کو ریکارڈ کرنے والے ایک نگرانی والے کیمرے کے طور پر۔ آڈیٹر بعد میں ویڈیو دیکھتا ہے۔ اگر کوئی خاص واقعہ پیش آنے پر کیمرہ آن نہیں ہوتا ہے، تو اس واقعہ کا کوئی ریکارڈ نہیں ہوگا اور اس کے لیے SOC2 کنٹرول میں ایک خلا ہوگا۔

کنٹرول 1: ایم ایف اے کو نافذ کریں (CC6.6)

ملٹی فیکٹر توثیق (MFA) آپ سے دو آزاد عوامل کا استعمال کرتے ہوئے اپنی شناخت کی تصدیق کرنے کا تقاضا کرتی ہے: کچھ جو آپ جانتے ہیں (آپ کا پاس ورڈ) اور کچھ آپ کے پاس ہے (آپ کا فون یا ہارڈویئر کلید)۔ MFA کے بغیر، پروڈکشن سسٹم تک رسائی کے لیے چوری شدہ پاس ورڈ کافی ہے۔

SOC2 CC6.6 کا تقاضہ ہے کہ سسٹمز تک رسائی مجاز صارفین تک محدود ہو۔ MFA ایک تکنیکی کنٹرول ہے جو "منظور شدہ” کو معنی خیز بناتا ہے۔ اس کے بغیر، پاس ورڈ کی خلاف ورزی پروڈکشن تک رسائی کا واقعہ بن جاتا ہے۔

MFA کو لاگو کرنے کے لیے، آپ اپنے شناختی فراہم کنندہ (Okta، Google Workspace، یا Azure AD) سے منسلک AWS IAM شناختی مرکز (سابقہ ​​SSO) استعمال کر سکتے ہیں۔ MFA پھر شناخت فراہم کرنے والے کی سطح پر نافذ کیا جاتا ہے۔ وہ صارفین جو MFA رجسٹرڈ نہیں ہیں وہ AWS سروس سے قطع نظر اس کی تصدیق نہیں کر سکیں گے جس سے وہ رابطہ قائم کرنے کی کوشش کر رہے ہیں۔

# IAM Identity Center configuration — MFA is enforced at the IdP level.
# No IAM user has direct console or CLI access.
# All access goes through SSO sessions (8-hour expiry by default).

resource "aws_ssoadmin_instance_access_control_attributes" "mfa" {
  instance_arn = tolist(data.aws_ssoadmin_instances.this.arns)[0]

  attribute {
    key = "email"
    value {
      source = ["$${path:email}"]
    }
  }
}

آپ اس بات کو یقینی بنا سکتے ہیں کہ آپ کے IAM صارفین براہ راست کنسول تک رسائی کو برقرار نہیں رکھتے ہیں (MFA کو نظرانداز کرتے ہوئے)۔

# Any user listed here has direct console access bypassing SSO — investigate immediately
aws iam list-users 
  --query 'Users[?PasswordLastUsed!=`null`].[UserName,PasswordLastUsed]' 
  --output table

کنٹرول 2: بنیادی ڈھانچہ بطور کوڈ (CC8.1)

انفراسٹرکچر بطور کوڈ (IaC) کا مطلب ہے کہ آپ کے کلاؤڈ انفراسٹرکچر کو ورژن کنٹرول شدہ کوڈ فائلوں (Terraform، Pulumi، یا AWS CDK) کے ساتھ بیان کرنا ہے بجائے اس کے کہ AWS کنسول کے ذریعے وسائل کو دستی طور پر تخلیق کیا جائے۔ تمام بنیادی ڈھانچے کی تبدیلیوں کو پل درخواستوں کے طور پر تجویز کیا جاتا ہے، ساتھیوں کے ذریعہ جائزہ لیا جاتا ہے، اور خودکار پائپ لائنوں کے ذریعے لاگو کیا جاتا ہے۔

SOC2 CC8.1 تبدیلی کے انتظام کو ایڈریس کرتا ہے (پروڈکشن ماحول میں تمام تبدیلیوں کو دستاویز کرنے، جائزہ لینے اور منظور کرنے کی ضرورت)۔ کنسول کی دستی تبدیلیاں آڈٹ ٹریل تیار نہیں کرتی ہیں۔ اگر کوئی انجینئر AWS کنسول کھولتا ہے اور Terraform سے گزرے بغیر ایک سیکورٹی گروپ بناتا ہے، تو وہ تبدیلی SOC2 آڈیٹر کے لیے نظر نہیں آئے گی۔ IaC آپ کو تمام تبدیلیوں کا جائزہ لینے اور ٹریک کرنے کی اجازت دیتا ہے۔

اب دیکھتے ہیں کہ یہاں IaC کو کیسے نافذ کیا جائے۔ یہ GitHub ایکشنز ورک فلو ٹیرافارم کو صرف ڈیفالٹ برانچ پر پل کی درخواست کا جائزہ لینے اور منظور ہونے کے بعد لاگو کرتا ہے۔ ورک فلو تمام بنیادی ڈھانچے کی تبدیلیوں کا ایک ناقابل تغیر ریکارڈ بناتے ہیں۔

# .github/workflows/terraform-apply.yml
name: Terraform Apply (Production)
on:
  push:
    branches: [main]
    paths: ['terraform/**']

permissions:
  id-token: write   # Required for AWS OIDC authentication
  contents: read

jobs:
  apply:
    name: Apply Infrastructure Changes
    runs-on: ubuntu-latest
    environment: production  # Requires manual approval for production

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Configure AWS credentials (OIDC — no long-lived keys)
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/terraform-apply
          aws-region: us-east-1

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: "1.6.0"

      - name: Terraform Plan
        run: |
          terraform init
          terraform plan -out=tfplan -input=false

      - name: Terraform Apply
        run: terraform apply -input=false tfplan

SOC2 ثبوت جس سے یہ پیدا ہوتا ہے: ہر بنیادی ڈھانچے کی تبدیلی کے لیے GitHub ایکشنز کے عمل درآمد کے لاگز، یہ دکھاتا ہے کہ اسے کس نے متحرک کیا (مطالعہ کی درخواست کو)، اسے کب لاگو کیا گیا، اور تبدیلی کیا تھی۔

کنٹرول 3: CloudTrail کو فعال کریں (CC7.1)

AWS CloudTrail ایک ایسی سروس ہے جو آپ کے AWS اکاؤنٹ میں کی گئی تمام API کالز کو ریکارڈ کرتی ہے (کس نے کال کی، کب، کس IP ایڈریس سے، اور آیا یہ کامیاب رہی)۔ اسے اپنے AWS ماحول میں ہونے والی ہر چیز کا مکمل آڈٹ لاگ سمجھیں۔

SOC2 CC7.1 کو سیکیورٹی ایونٹ کی نگرانی کی ضرورت ہے۔ CloudTrail ڈیفالٹ لاگنگ پرت ہے۔ CloudTrail کے بغیر، آپ غیر مجاز رسائی کا پتہ نہیں لگا سکتے، واقعات کی چھان بین نہیں کر سکتے، یا آڈیٹرز کو یہ ثابت نہیں کر سکتے کہ آپ کے کنٹرول حسب منشا کام کر رہے ہیں۔ آڈیٹرز جن کے پاس ماضی کی AWS API سرگرمی میں مرئیت نہیں ہے وہ اس بات کی تصدیق نہیں کر سکتے کہ آیا مشاہدے کی مدت کے دوران رسائی کے کنٹرول نافذ کیے گئے تھے۔

اس کو لاگو کرنے کے لیے، آپ کو ملٹی ریجن کلاؤڈ ٹریل کو فعال کرنا چاہیے تاکہ یہ یقینی بنایا جا سکے کہ تمام AWS ریجنز میں سرگرمی پکڑی گئی ہے، بشمول IAM جیسی عالمی خدمات۔ کیونکہ لاگز کو ایک S3 بالٹی میں آبجیکٹ لاک کے ساتھ بھیجا جا سکتا ہے (ثبوت جمع کرنے والے حصے میں کنٹرول 3 اس کا احاطہ کرتا ہے)، آپ لاگز میں ترمیم یا حذف نہیں کر سکتے ہیں۔

# Enable CloudTrail with log file validation and multi-region coverage
aws cloudtrail create-trail 
  --name production-audit-trail 
  --s3-bucket-name your-cloudtrail-logs-bucket 
  --is-multi-region-trail 
  --enable-log-file-validation 
  --include-global-service-events

# Start the trail (creation alone does not start logging)
aws cloudtrail start-logging --name production-audit-trail

# Verify the trail is active and logging
aws cloudtrail get-trail-status --name production-audit-trail 
  --query '{IsLogging:IsLogging,LatestDeliveryTime:LatestDeliveryTime}'

کنٹرول 4: گارڈ ڈیوٹی کو فعال کریں (CC7.2)

AWS GuardDuty ایک خطرے کا پتہ لگانے کی خدمت ہے جو CloudTrail لاگز، VPC فلو لاگز، اور DNS لاگز کا تجزیہ کرتی ہے۔ ہم مشتبہ رویے کی شناخت کے لیے مشین لرننگ کا استعمال کرتے ہیں، جیسے کہ معلوم میلویئر سرورز کے ساتھ بات چیت کرنے والے EC2 واقعات، غیر معمولی ممالک سے لاگ ان ہونے والے IAM صارفین، یا غیر معمولی API کال پیٹرن جو اسناد کی چوری کی نشاندہی کرتے ہیں۔

SOC2 CC7.2 کو ممکنہ حفاظتی واقعات کی شناخت کے لیے پتہ لگانے والے آلات کے استعمال کی ضرورت ہے۔ گارڈ ڈیوٹی ایک مانیٹرنگ پرت ہے جو آپ کو مطلع کرتی ہے جب کوئی غیر معمولی چیز واقع ہوتی ہے، نیز حقیقت کے بعد کیا ہوتا ہے۔ اس کے بغیر، آپ کو نقصان پہنچنے کے بعد ہی سمجھوتہ ملے گا۔

عمل درآمد مندرجہ ذیل ہے:

# Enable GuardDuty — findings published every 15 minutes for active threats
aws guardduty create-detector 
  --enable 
  --finding-publishing-frequency FIFTEEN_MINUTES

# Verify GuardDuty is active
aws guardduty list-detectors --query 'DetectorIds' --output table

آپ واقعہ رسپانس چینلز پر کریٹیکل اور ہائی سیوریٹی گارڈ ڈیوٹی فائنڈنگز کو فوری طور پر روٹ کرنے کے لیے ایونٹ برج کے قوانین ترتیب دے سکتے ہیں۔ جن نتائج کا 90 دنوں سے جائزہ نہیں لیا گیا ہے وہ SOC2 کے اہل ہیں۔

کنٹرول 5: VPC فلو لاگ (CC6.1)

VPC فلو لاگز آپ کے ورچوئل پرائیویٹ کلاؤڈ سے گزرنے والے آئی پی ٹریفک کے بارے میں معلومات حاصل کرتے ہیں (تمام اجازت یافتہ اور نامنظور کنکشنز، بشمول سورس آئی پی، ڈیسٹینیشن آئی پی، پورٹ، پروٹوکول، اور آیا ٹریفک کی اجازت ہے یا انکار)۔ نیٹ ورک کی سطح کا آڈٹ ٹریل جو CloudTrail فراہم نہیں کرتا ہے۔

SOC2 CC6.1 کو منطقی رسائی کنٹرول اور نگرانی کی ضرورت ہے۔ VPC فلو لاگز آپ کو اس بات کی تصدیق کرنے کی اجازت دیتے ہیں کہ نیٹ ورک کی تقسیم درحقیقت کام کر رہی ہے (آپ جس ٹریفک کو مسترد کرتے ہیں وہ لاگز میں انکار کے طور پر ظاہر ہو جائے گا)، سروسز کے درمیان غیر متوقع مواصلت کا پتہ لگاتا ہے، اور نیٹ ورک پرت پر سیکیورٹی کے واقعات کی تحقیقات کرتا ہے۔

# Create an IAM role for VPC Flow Logs to deliver to CloudWatch
aws iam create-role 
  --role-name vpc-flow-logs-role 
  --assume-role-policy-document '{
    "Version":"2012-10-17",
    "Statement":[{
      "Effect":"Allow",
      "Principal":{"Service":"vpc-flow-logs.amazonaws.com"},
      "Action":"sts:AssumeRole"
    }]
  }'

# Enable VPC Flow Logs for all traffic (ACCEPT and REJECT)
aws ec2 create-flow-logs 
  --resource-ids vpc-YOUR_PRODUCTION_VPC_ID 
  --resource-type VPC 
  --traffic-type ALL 
  --log-group-name /aws/vpc/flow-logs/production 
  --deliver-log-permission-arn arn:aws:iam::YOUR_ACCOUNT_ID:role/vpc-flow-logs-role

# Verify flow logs are active
aws ec2 describe-flow-logs 
  --filter Name=resource-id,Values=vpc-YOUR_PRODUCTION_VPC_ID 
  --query 'FlowLogs[*].{Status:FlowLogStatus,LogGroup:LogGroupName}'

کنٹرول 6: سیکرٹس مینیجر (CC6.7)

سیکرٹ مینجمنٹ کا مطلب ہے آپ کی اسناد (ڈیٹا بیس سیکرٹس، API کیز، سرٹیفکیٹس، اور دیگر حساس کنفیگریشن ویلیوز) کو ایک سرشار، رسائی پر قابو پانے والی سروس (جیسے AWS Secrets Manager یا HashiCorp Vault) میں محفوظ کرنا ہے۔ .env یہ ایک فائل، GitHub ریپوزٹری سیکریٹ، یا ایپلیکیشن کوڈ میں ہارڈ کوڈ ہے۔

SOC2 CC6.7 کا تقاضا ہے کہ سسٹم کے اہم اجزاء کو غیر مجاز رسائی سے محفوظ رکھا جائے۔ میں محفوظ کردہ راز .env ریپوزٹری سے وابستہ فائلیں تمام ڈویلپرز کے لیے قابل رسائی ہیں جن کے پاس ریپوزٹری تک رسائی ہے، تمام CI/CD ایگزیکیوٹرز، اور تمام انجینئرز جنہوں نے ریپوزٹری کو کلون کیا ہے (یہاں تک کہ وہ بھی جنہوں نے کمپنی چھوڑ دی ہے)۔

سیکرٹس مینیجر سنٹرلائزڈ سٹوریج، لاگنگ تک رسائی، خودکار گردش، اور دانے دار IAM اجازتیں فراہم کرتا ہے تاکہ صرف مخصوص سروسز ہی مخصوص راز بازیافت کر سکیں۔

آئیے نفاذ کو دیکھتے ہیں (خفیہ اسٹوریج اور گردش):

# Store a database credential with automatic 90-day rotation
aws secretsmanager create-secret 
  --name production/postgresql/credentials 
  --description "Production PostgreSQL credentials — rotated every 90 days" 
  --secret-string '{
    "username": "app_user",
    "password": "REPLACE_WITH_STRONG_PASSWORD",
    "host": "your-rds-endpoint.us-east-1.rds.amazonaws.com",
    "port": 5432,
    "dbname": "production"
  }'

# Enable automatic rotation every 90 days
aws secretsmanager rotate-secret 
  --secret-id production/postgresql/credentials 
  --rotation-rules AutomaticallyAfterDays=90

ایپلیکیشن رن ٹائم پر راز کو کیسے بازیافت کرتی ہے (کوئی ہارڈ کوڈ شدہ اسناد نہیں):

# Good: secret retrieved at runtime from Secrets Manager
import boto3
import json

def get_db_credentials():
    client = boto3.client('secretsmanager', region_name="us-east-1")
    response = client.get_secret_value(SecretId='production/postgresql/credentials')
    return json.loads(response['SecretString'])

# Bad: secret hardcoded in application code or .env file
DB_PASSWORD = "my_database_password_123"  # Never do this

CloudTrail کے رسائی لاگز ہر بار سیکیورٹی کی معلومات حاصل کرنے پر ریکارڈ کرتے ہیں، جس کے ذریعے IAM کا کردار، اور کب۔ نوشتہ جات SOC2 ثبوت ہیں کہ خفیہ رسائی کنٹرول اور قابل سماعت ہے۔

کنٹرول 7: EBS انکرپشن (CC6.1)

لچکدار بلاک اسٹور (EBS) انکرپشن اس بات کو یقینی بناتا ہے کہ EC2 مثالوں سے منسلک اور RDS ڈیٹا بیس کے ذریعے استعمال ہونے والی مستقل ڈسکیں AES-256 کا استعمال کرتے ہوئے آرام سے انکرپٹ ہو جائیں۔ اگر AWS ملازم یا حملہ آور کو آپ کے اسٹوریج ہارڈویئر تک جسمانی رسائی حاصل ہے، تو وہ آپ کے ڈیٹا کو خفیہ کاری کی کلید کے بغیر نہیں پڑھ سکیں گے۔

SOC2 CC6.1 کو معلومات کے اثاثوں کو غیر مجاز رسائی سے بچانے کی ضرورت ہے۔ آرام میں خفیہ کاری ایک ایسا کنٹرول ہے جو ڈیٹا کی حفاظت کرتا ہے اگر فزیکل اسٹوریج کو نقصان پہنچا ہو یا ڈسکوں کو غلط طریقے سے ٹھکانے لگایا گیا ہو۔ آپ کے اکاؤنٹ میں فعال ہونے پر، تمام نئے EBS والیومز خود بخود انکرپٹ ہو جائیں گے، بشمول RDS اسٹوریج، EKS نوڈ والیوم، اور EC2 مثال کے روٹ والیوم۔

# Enable EBS encryption by default for all new volumes in this region
aws ec2 enable-ebs-encryption-by-default

# Verify it is enabled
aws ec2 get-ebs-encryption-by-default 
  --query 'EbsEncryptionByDefault'
# Expected output: true

# Check existing volumes — any showing false need to be migrated
aws ec2 describe-volumes 
  --query 'Volumes[?Encrypted==`false`].[VolumeId,Size,VolumeType]' 
  --output table

کسی بھی موجودہ غیر خفیہ شدہ والیوم کو سنیپ شاٹس سے تبدیل کرنا ضروری ہے۔ عمل: ایک غیر خفیہ شدہ والیوم کا سنیپ شاٹ لیں، اسنیپ شاٹ سے ایک نیا انکرپٹڈ والیوم بنائیں، اور مثال کے طور پر اس کا تبادلہ کریں۔

کنٹرول 8: بلاک S3 عوامی رسائی (CC6.1)

Amazon S3 بالٹیوں کو عوامی رسائی کی اجازت دینے کے لیے ترتیب دیا جا سکتا ہے۔ اس کا مطلب یہ ہے کہ انٹرنیٹ پر کوئی بھی آپ کے مواد کو بغیر تصدیق کے پڑھ سکتا ہے۔ عوامی رسائی کو مسدود کرنا ایک اکاؤنٹ کی سطح اور بالٹی سطح کی ترتیب ہے جو بالٹی کی اپنی پالیسیوں سے قطع نظر، بالٹی کو عوامی ہونے سے روکتی ہے۔

غلط کنفیگرڈ S3 بالٹیاں کلاؤڈ ماحول میں ڈیٹا کی خلاف ورزی کی سب سے عام وجوہات میں سے ایک ہیں۔ اکاؤنٹ کی سطح پر عوامی رسائی کو مسدود کرنا اس بات کو یقینی بناتا ہے کہ ڈویلپرز غلطی سے صارف کے ڈیٹا پر مشتمل بالٹیوں کو بے نقاب نہیں کر سکتے، چاہے وہ غلط بالٹی پالیسی ترتیب دیں۔ یہ چوکیاں ہیں، نہ صرف پالیسیاں۔

# Block public access at the AWS account level — applies to all buckets
aws s3control put-public-access-block 
  --account-id YOUR_ACCOUNT_ID 
  --public-access-block-configuration 
    BlockPublicAcls=true,
    IgnorePublicAcls=true,
    BlockPublicPolicy=true,
    RestrictPublicBuckets=true

# Verify account-level setting is active
aws s3control get-public-access-block 
  --account-id YOUR_ACCOUNT_ID

# Scan for any buckets that have public access enabled (should be zero)
aws s3api list-buckets --query 'Buckets[*].Name' --output text | 
  tr 't' 'n' | while read bucket; do
    result=((aws s3api get-public-access-block --bucket ")bucket" 2>/dev/null)
    if echo "$result" | grep -q '"BlockPublicAcls": false'; then
      echo "WARNING: $bucket has public access not fully blocked"
    fi
  done

کنٹرول 9: برانچ پروٹیکشن (CC8.1)

برانچ پروٹیکشن ایک GitHub سیٹنگ ہے جو انجینئرز کو کوڈ کو براہ راست مین برانچ میں پُش کرنے سے روکتی ہے بغیر کسی پل کی درخواست کے جس کا جائزہ لیا گیا ہو اور کم از کم ایک دوسرے ٹیم ممبر نے اسے منظور کیا ہو۔ مزید برآں، انضمام کوڈ کے لیے اسے CI پائپ لائن سے گزرنا ہوتا ہے۔

SOC2 CC8.1 کو تبدیلی کے انتظام کی ضرورت ہے۔ یعنی، ضرورت یہ ہے کہ پیداواری نظام میں ہونے والی تمام تبدیلیوں کو دستاویزی، نظرثانی اور منظوری دی جائے۔ برانچ پروٹیکشن کے بغیر، انجینئرز براہ راست مین کی طرف دھکیل سکتے ہیں، جو بغیر کسی جائزے یا آڈٹ ٹریل کے CI/CD پائپ لائن کے ذریعے براہ راست پروڈکشن میں لگائی جاتی ہے۔ برانچ کا تحفظ تبدیلی کے انتظام کی پالیسی کا تکنیکی نفاذ ہے۔

ایک اہم ترتیب جس سے زیادہ تر ٹیمیں چھوٹ جاتی ہیں: "اوپر کی ترتیبات کے بائی پاس کی اجازت نہ دیں” کا اختیار فعال ہونا چاہیے۔ اس کے بغیر، منتظمین برانچ کے تحفظ کو نظرانداز کر سکتے ہیں اور SOC2 آڈیٹرز اسے خالی کے بطور نشان زد کر دیں گے۔ اس کی وجہ یہ ہے کہ اس کا مطلب ہے کہ تبدیلی کے انتظامی کنٹرولز کو نظرانداز کیا جا سکتا ہے۔

# .github/settings.yml — enforces branch protection via code
# Requires the settings GitHub App: https://github.com/apps/settings

branches:
  - name: main
    protection:
      required_pull_request_reviews:
        required_approving_review_count: 1
        dismiss_stale_reviews: true
        require_code_owner_reviews: false
      required_status_checks:
        strict: true
        contexts:
          - "CI / test"
          - "Security / trivy-scan"
      enforce_admins: true         # Admins cannot bypass — this is critical
      restrictions: null           # No push restriction beyond the above
      allow_force_pushes: false
      allow_deletions: false

اس بات کو یقینی بنانے کا طریقہ یہ ہے کہ برانچ پروٹیکشن اثر میں ہے اور ایڈمنسٹریٹر اسے نظرانداز نہیں کر سکتے:

# Returns the branch protection rules including enforce_admins status
curl -H "Authorization: token YOUR_GITHUB_TOKEN" 
  https://api.github.com/repos/YOUR_ORG/YOUR_REPO/branches/main/protection 
  | jq '{enforce_admins: .enforce_admins.enabled, required_reviews: .required_pull_request_reviews.required_approving_review_count}'

کنٹرول 10: کنٹینر امیج اسکیننگ (CC7.4)

کنٹینر امیج اسکیننگ آپریٹنگ سسٹم پیکیج میں معلوم سیکیورٹی کمزوریوں (CVEs) اور اس میں موجود ایپلیکیشن انحصارات کی شناخت کے لیے تعیناتی سے پہلے ڈاکر امیجز کا تجزیہ کرتی ہے۔

ٹریوی ایک اوپن سورس سکینر ہے جو قومی کمزوری ڈیٹا بیس کے خلاف بیس امیجز (اوبنٹو، الپائن، وغیرہ)، تمام انسٹال کردہ OS پیکجز، اور زبان سے متعلق انحصار (npm، pip، Go ماڈیولز) کو چیک کرتا ہے۔

SOC2 CC7.4 کو کمزوریوں کی نگرانی اور شناخت کی ضرورت ہے۔ ہر کنٹینر جو آپ تعینات کرتے ہیں اس میں ایک بنیادی تصویر شامل ہوتی ہے جس میں OS پیکیج شامل ہوتا ہے، اور وہ پیکیج باقاعدگی سے CVE انکشافات وصول کرتے ہیں۔ ایک اہم CVE جو پروڈکشن کنٹینر میں 90 دنوں تک بغیر پیچ کے رہتا ہے وہ SOC2 کی تلاش ہے۔ CI کی خودکار اسکیننگ کا مطلب ہے کہ ہر تصویر کو تعیناتی سے پہلے چیک کیا جاتا ہے۔

# .github/workflows/security-scan.yml
name: Security Scan
on: [push, pull_request]

jobs:
  trivy-scan:
    name: Container Vulnerability Scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Build container image
        run: docker build -t app:${{ github.sha }} .

      - name: Scan image for vulnerabilities
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: app:${{ github.sha }}
          format: sarif
          output: trivy-results.sarif
          severity: CRITICAL,HIGH
          exit-code: 1          # Fail the pipeline on CRITICAL or HIGH findings

      - name: Upload results to GitHub Security tab
        uses: github/codeql-action/upload-sarif@v2
        if: always()            # Upload even if scan found issues
        with:
          sarif_file: trivy-results.sarif

سکینر تلاش کرتا ہے:

  • بیس امیج OS پیکجز میں CVEs (مثال کے طور پر Ubuntu پر OpenSSL کی اہم کمزوری)

  • ایپلیکیشن انحصار کے کمزور ورژن (آپ کی ایپ کے ذریعہ استعمال ہونے والے npm پیکیجز میں معلوم RCEs)

  • خود ڈاکر فائل کی غلط کنفیگریشن (روٹ کے طور پر چل رہی ہے، استعمال کرتے ہوئے: latest ٹیگ)

نتائج آپ کے ذخیرے کے GitHub سیکیورٹی ٹیب میں دکھائے جاتے ہیں، جو تمام اسکینوں کا تاریخی ریکارڈ فراہم کرتے ہیں جو SOC2 ثبوت ہیں۔

کنٹرول 11: واقعہ رسپانس پلان (CC9.2)

واقعہ کے جواب کا منصوبہ ایک تحریری، آزمائشی طریقہ کار ہے جو اس بات کی وضاحت کرتا ہے کہ جب کوئی سیکیورٹی واقعہ پیش آتا ہے تو آپ کی ٹیم کیا کرے گی، اس لمحے سے لے کر صارف کی اطلاع اور واقعے کے بعد کے جائزہ تک الرٹ جاری کیا جاتا ہے۔

SOC2 CC9.2 کا تقاضہ ہے کہ آپ کے پاس حفاظتی واقعات کا جواب دینے کے لیے ایک دستاویزی عمل ہو اور آپ اس کی جانچ کریں۔ آڈیٹر کو تحریری کارکردگی کی دستاویزات اور اس بات کا ثبوت درکار ہوگا کہ مشق (سماجی تقریب کی مشق) مشاہدے کی مدت کے اندر کی گئی تھی۔

واقعہ کے ردعمل کی رن بک میں شامل ہونا چاہئے:

  1. شدت کی درجہ بندی: P1 کی تعریفیں (پروڈکشن کی بندش، کسٹمر کا ڈیٹا خطرے میں)، P2 (سروس کی تنزلی، ممکنہ خطرہ) اور P3 (معمولی مسئلہ، گاہک پر کوئی اثر نہیں) اور ہر ایک کے لیے متعلقہ SLAs۔

  2. بڑھنے کا راستہ: ہر شدت کی سطح پر کال موصول کرنے والے عین مطابق شخص کے ساتھ ان کے رابطے کی تفصیلات۔ "آن ڈیوٹی انجینئر” نہیں۔ اگر پہلا شخص 10 منٹ کے اندر جواب نہیں دیتا ہے تو مخصوص نام اور بیک اپ فراہم کریں۔

  3. پہلے 15 منٹ: فوری طور پر اٹھانے کے لیے مخصوص اقدامات متاثرہ نظام کو الگ تھلگ کرنا، دائرہ کار کا اندازہ لگانا، واقعے کے چینلز کو مطلع کرنا، اور ٹائم لائن لاگ کو شروع کرنا ہے۔

  4. مواصلاتی سانچہ: پہلے سے تیار کردہ سلیک پیغامات، کسٹمر ای میل ٹیمپلیٹس، اور ریگولیٹری نوٹیفکیشن ٹیمپلیٹس (GDPR کو 72 گھنٹے کے اندر اطلاع درکار ہے، HIPAA کو 60 دنوں کے اندر اطلاع درکار ہے)۔

  5. حادثے کے بعد کا جائزہ: بے قصور پوسٹ مارٹم عمل، 5 بنیادی وجہ تجزیہ ٹیمپلیٹس، ایکشن آئٹم سے باخبر رہنے کا عمل۔

مشاہدے کی مدت کے دوران کم از کم ایک فرضی مشق کریں۔ اپنی انجینئرنگ ٹیم کو 45 منٹ کے لیے اکٹھا کریں تاکہ حقیقت پسندانہ منظر نامہ تیار کیا جا سکے (مثلاً "AWS رسائی کی چابیاں عوامی GitHub ریپوزٹری کے لیے پرعزم ہیں”) اور رن بک کے ساتھ مل کر چلیں۔ دستاویز میٹنگ کی تاریخیں، حاضرین، منظرنامے، پائے گئے خلا، اور اصلاحی اقدامات۔ یہ دستاویز آپ کا ثبوت ہے۔

کنٹرول 12: رسائی کا جائزہ (CC6.3)

رسائی کے جائزے اس بات کا سہ ماہی آڈٹ ہوتے ہیں کہ آپ کے پروڈکشن سسٹمز پر کس کی رسائی ہے، بشمول AWS اکاؤنٹس، GitHub ریپوزٹریز، پروڈکشن ڈیٹا بیس، اور کوئی بھی SaaS ٹولز جو کسٹمر ڈیٹا کے ساتھ رابطے میں آتے ہیں۔ تصدیق کریں کہ فہرست میں شامل ہر شخص اب بھی کمپنی میں کام کرتا ہے اور اسے اب بھی اپنے کردار کی بنیاد پر دی گئی رسائی کی ضرورت ہے۔

SOC2 CC6.3 تک رسائی کو منسوخ کرنے کی ضرورت ہوتی ہے جب مزید ضرورت نہ ہو۔ پروڈکشن AWS اکاؤنٹ تک رسائی کو برقرار رکھنے والا ایک سابق ملازم ایک حقیقی حفاظتی خطرہ اور ایک واضح SOC2 تلاش کی نمائندگی کرتا ہے۔

رسائی کے ہر جائزے میں جو میں نے کیا ہے، کم از کم 3-5 سابق ملازمین یا ٹھیکیدار ابھی تک فعال رسائی کے ساتھ نہیں ہونے چاہئیں۔

سہ ماہی رسائی جائزہ چیک لسٹ:

# 1. IAM users — list all with their last login date
aws iam generate-credential-report
aws iam get-credential-report --output text --query Content 
  | base64 --decode | cut -d',' -f1,5 | column -t -s ','

# 2. IAM roles — find roles that have not been used in 90+ days
aws iam get-account-authorization-details 
  --query 'RoleDetailList[*].{Role:RoleName,LastUsed:RoleLastUsed.LastUsedDate}' 
  --output table

# 3. Verify AWS SSO user list matches your current employee list
aws identitystore list-users 
  --identity-store-id YOUR_IDENTITY_STORE_ID 
  --query 'Users[*].{Name:DisplayName,Email:Emails[0].Value}' 
  --output table

اپنے HR سسٹم سے موجودہ ملازمین کی فہرست کے ساتھ آؤٹ پٹ کا حوالہ دیں۔ تمام تبدیلیوں کو دستاویز کریں۔ رسائی ہٹا دی جاتی ہے، مراعات کم ہو جاتی ہیں، اور اکاؤنٹس کو غیر فعال کر دیا جاتا ہے۔ دستاویزی تبدیلیاں اس بات کا ثبوت ہیں کہ جائزہ بامعنی طور پر کیا گیا تھا نہ کہ صرف چیک باکس کی مشق۔

کنٹرول 13: بیک اپ تصدیق (CC9.5)

بیک اپ کی توثیق دراصل بیک اپ کو بحال کرنے کا عمل ہے تاکہ یہ یقینی بنایا جا سکے کہ یہ کام کر رہا ہے، بجائے اس کے کہ بیک اپ بنایا جا رہا ہے۔ بحالی کے نقطہ نظر سے غیر تجربہ شدہ بیک اپ غیر موجود ہیں۔

SOC2 CC9.5 کو بحالی کے طریقہ کار کی جانچ کی ضرورت ہے۔ پہلی دریافت یہ ہے کہ پروڈکشن ڈیٹا بیس خراب ہو گیا ہے اور واقعے کے دوران خودکار RDS اسنیپ شاٹس کو بحال نہیں کیا جا سکتا، جس کے نتیجے میں تباہی کی بحالی میں ناکامی اور SOC2 کے نتائج دونوں ہی نکلتے ہیں۔

اپنے RDS بیک اپ کی جانچ کیسے کریں:

# Step 1: Find your most recent production snapshot
aws rds describe-db-snapshots 
  --db-instance-identifier your-production-db 
  --query 'sort_by(DBSnapshots, &SnapshotCreateTime)[-1].DBSnapshotIdentifier' 
  --output text

# Step 2: Restore the snapshot to a test instance
aws rds restore-db-instance-from-db-snapshot 
  --db-instance-identifier backup-verification-test 
  --db-snapshot-identifier YOUR_SNAPSHOT_ID 
  --db-instance-class db.t3.medium 
  --no-publicly-accessible 
  --tags Key=Purpose,Value=backup-verification Key=Environment,Value=test

# Step 3: Wait for the restore to complete (typically 5–15 minutes)
aws rds wait db-instance-available 
  --db-instance-identifier backup-verification-test

# Step 4: Connect and verify data integrity (spot check key tables)
# Run this against the restored instance
psql -h RESTORED_INSTANCE_ENDPOINT -U your_user -d your_database 
  -c "SELECT COUNT(*) FROM users; SELECT MAX(created_at) FROM orders;"

# Step 5: Document the test result and delete the test instance
aws rds delete-db-instance 
  --db-instance-identifier backup-verification-test 
  --skip-final-snapshot

دستاویز کی جانچ کی تاریخیں، استعمال شدہ سنیپ شاٹس، بحالی کے اوقات، ڈیٹا کی توثیق کے استفسار کے نتائج، اور ٹیسٹ کس نے انجام دیے۔ اسے کم از کم سہ ماہی چلائیں۔ یہ دستاویز CC9.5 کے لیے SOC2 ثبوت ہے۔

کنٹرول 14: مینجمنٹ لاگ تبدیل کریں (CC8.1)

تبدیلی کا انتظام لاگ ان تمام تبدیلیوں کا قابل سماعت ریکارڈ ہے جو پروڈکشن ماحول میں کی گئی ہیں: تبدیلیاں کیا تھیں، کس نے انہیں منظور کیا، اور ان کا اطلاق کب ہوا۔

SOC2 CC8.1 کا تقاضہ ہے کہ پیداواری ماحول میں ہونے والی تبدیلیوں کی منظوری اور دستاویز کی جائے۔ IaC اور GitOps کے ساتھ، آپ کے پاس پہلے سے ہی ناقابل تغیر تبدیلی کی تاریخ کے دو الگ الگ ذرائع ہیں جو مل کر اس کنٹرول کو پورا کرتے ہیں۔

GitHub پل کی درخواست کی تاریخ تمام کوڈ اور بنیادی ڈھانچے کی تبدیلیوں کا ریکارڈ فراہم کرتا ہے، بشمول PR کس نے کھولا، کس نے PR کا جائزہ لیا اور اسے منظور کیا، CI کی حیثیت کیا ہے، اور اسے کب ضم کیا گیا تھا۔ یہ ایپلیکیشن اور انفراسٹرکچر کی تبدیلیوں کے لیے تبدیلی کا انتظام لاگ ہے۔

ArgoCD مطابقت پذیری کی تاریخ آپ کے Kubernetes کلسٹر میں تمام تعیناتیوں کی تاریخ فراہم کرتا ہے (ایپلی کیشنز کی مطابقت پذیری، Git کمٹ، وقت، مطابقت پذیری کامیاب یا نہیں)۔

ثبوت کے طور پر ArgoCD مطابقت پذیری کی تاریخ برآمد کرنے کے لیے:

# Export ArgoCD application sync history as JSON evidence
argocd app history YOUR_APP_NAME --output json > argocd-sync-history-$(date +%Y%m).json

# Upload to your SOC2 evidence bucket
aws s3 cp argocd-sync-history-$(date +%Y%m).json 
  s3://your-soc2-evidence-bucket/change-management/$(date +%Y/%m)/

# For each deployment, the evidence contains:
# - App name, deployed revision (Git commit SHA)
# - Deployment timestamp
# - Initiating user or automated sync
# - Success/failure status

GitHub PR کی تاریخ اور ArgoCD مطابقت پذیر تاریخ آڈیٹرز کو مشاہدے کی مدت کے دوران پیداواری ماحول میں کی گئی تمام تبدیلیوں کا مکمل، چھیڑ چھاڑ کا واضح ریکارڈ فراہم کرتی ہے۔

ہفتے 7-10: ثبوت جمع کرنے کا بنیادی ڈھانچہ

ثبوت SOC2 پاس کرنے اور ناکام ہونے کے درمیان فرق ہے۔

آپ سوچ رہے ہوں گے: اصل ثبوت کیا ہے؟ SOC2 اصطلاحات میں، ثبوت وہ دستاویزات ہیں جو یہ ظاہر کرتی ہیں کہ مخصوص کنٹرولز مشاہدے کی مدت کے اندر ایک مخصوص نقطہ پر صحیح طریقے سے کام کرتے ہیں۔ پالیسی دستاویز میں کہا گیا ہے کہ آپ کچھ کریں گے۔ شواہد سے ثابت ہوتا ہے کہ آپ نے وہ چیزیں کیں، اور یہ کہ آپ نے انہیں مستقل طور پر کیا، نہ صرف آڈٹ سے ایک ہفتہ پہلے۔

مثال کے طور پر:

  • ایم ایف اے انفورسمنٹ (کنٹرول 1) کے لیے، ثبوت IAM شناختی مرکز MFA سیٹنگز کا اسکرین شاٹ ہے جو مشاہدے کے دورانیے کے دوران ایک مخصوص دن لیا گیا ہے، جس میں ایک IAM شناختی رپورٹ کے ساتھ یہ ظاہر ہوتا ہے کہ کسی بھی IAM صارف کو کنسول تک رسائی حاصل نہیں ہے۔

  • گارڈ ڈیوٹی (کنٹرول 4) کے لیے، شواہد میں گارڈ ڈیوٹی کنسول کے اسکرین شاٹس شامل ہیں جو فعال ڈٹیکٹر دکھاتے ہیں اور اس مدت کے دوران نتائج کے دستاویزی جوابات دکھاتے ہیں۔

  • رسائی کے جائزوں کے لیے (کنٹرول 12)، ثبوت تاریخ، نام، اور مخصوص رسائی کی تبدیلیوں کے ساتھ مکمل رسائی کے جائزے کے دستاویزات ہیں۔

دستی کام پر سینکڑوں گھنٹے صرف کیے بغیر 3 سے 12 ماہ کے عرصے میں مسلسل اس ثبوت کو اکٹھا کرنا چیلنج ہے۔ حل ایک خودکار ثبوت جمع کرنے کا بنیادی ڈھانچہ ہے۔

ثبوت کی بالٹی – آڈٹ ثبوت کے لیے چھیڑ چھاڑ کا ثبوت

ثبوت والی بالٹی ایک S3 بالٹی ہے جس میں آبجیکٹ لاکنگ کو گورننس موڈ میں فعال کیا گیا ہے۔ آبجیکٹ لاکنگ اشیاء کو برقرار رکھنے کی مخصوص مدت کے لیے حذف یا ترمیم کرنے سے روکتا ہے، اس صورت میں 365 دن۔ اس کا مطلب یہ ہے کہ ایک بار ثبوت اپ لوڈ ہو جانے کے بعد، منتظم تک رسائی کے حامل صارفین بھی اسے تبدیل نہیں کر سکتے (واضح طور پر لاک کو اوور رائیڈ کیے بغیر، جو اس کا اپنا آڈٹ ٹریل بناتا ہے)۔

چھیڑ چھاڑ کی یہ خصوصیات آڈیٹرز کو اعتماد فراہم کرتی ہیں کہ حقیقت کے بعد ثبوت تخلیق یا تبدیل نہیں کیے گئے ہیں۔

# terraform/soc2-evidence-bucket.tf

resource "aws_s3_bucket" "soc2_evidence" {
  bucket = "({var.company_name}-soc2-evidence-){var.environment}"
}

# Block all public access to the evidence bucket
resource "aws_s3_bucket_public_access_block" "soc2_evidence" {
  bucket = aws_s3_bucket.soc2_evidence.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

# Enable versioning so overwrites create new versions, not replacements
resource "aws_s3_bucket_versioning" "soc2_evidence" {
  bucket = aws_s3_bucket.soc2_evidence.id
  versioning_configuration {
    status = "Enabled"
  }
}

# Object Lock in GOVERNANCE mode — objects cannot be deleted for 365 days
resource "aws_s3_bucket_object_lock_configuration" "soc2_evidence" {
  bucket = aws_s3_bucket.soc2_evidence.id

  rule {
    default_retention {
      mode = "GOVERNANCE"
      days = 365
    }
  }
}

# Encrypt all evidence at rest
resource "aws_s3_bucket_server_side_encryption_configuration" "soc2_evidence" {
  bucket = aws_s3_bucket.soc2_evidence.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

ڈیلی ایویڈینس کلکٹر لیمبڈا

یہ Lambda فنکشن ہر روز خودکار طور پر چلتا ہے اور آپ کے ثبوت کی بالٹی میں ٹائم اسٹیمپڈ JSON فائل میں ہر اہم کنٹرول کی حیثیت کو برآمد کرتا ہے۔ 3 سے 12 ماہ کے مشاہدے کی مدت میں، روزانہ ریکارڈز یہ ثابت کرنے کے لیے تیار کیے جاتے ہیں کہ کنٹرولز فعال اور کام کر رہے ہیں۔

یہ خصوصیت خود بخود سات کنٹرولز کو چیک کرتی ہے: کلاؤڈ ٹریل ہیلتھ، گارڈ ڈیوٹی ہیلتھ، وی پی سی فلو لاگ، S3 پبلک ایکسس بلاکنگ، ای بی ایس انکرپشن، ایم ایف اے کمپلائنس، اور گارڈ ڈیوٹی فائنڈنگز شمار۔ ہر یومیہ سنیپ شاٹ آبجیکٹ لاکنگ کے ساتھ اپ لوڈ کیا جاتا ہے اور اس میں ترمیم نہیں کی جا سکتی۔

# lambda/evidence-collector/handler.py

import boto3
import json
from datetime import datetime, timedelta, timezone

def lambda_handler(event, context):
    """
    Daily SOC2 evidence collector.
    Runs at 00:00 UTC every day via EventBridge scheduler.
    Exports control status to S3 evidence bucket with Object Lock.
    """
    evidence = {
        'collection_timestamp': datetime.now(timezone.utc).isoformat(),
        'collection_date': datetime.now(timezone.utc).strftime('%Y-%m-%d'),
        'account_id': boto3.client('sts').get_caller_identity()['Account'],
        'controls': {}
    }

    # Control 3: CloudTrail status
    cloudtrail = boto3.client('cloudtrail')
    trails = cloudtrail.describe_trails(includeShadowTrails=False)['trailList']
    multi_region_trails = [t for t in trails if t.get('IsMultiRegionTrail')]
    evidence['controls']['cloudtrail'] = {
        'status': 'PASS' if multi_region_trails else 'FAIL',
        'detail': f"{len(multi_region_trails)} multi-region trail(s) active",
        'trails': [t['Name'] for t in multi_region_trails]
    }

    # Control 4: GuardDuty status
    guardduty = boto3.client('guardduty')
    detectors = guardduty.list_detectors()['DetectorIds']
    unresolved_critical = 0
    for detector_id in detectors:
        findings = guardduty.list_findings(
            DetectorId=detector_id,
            FindingCriteria={
                'Criterion': {
                    'severity': {'Gte': 7},  # HIGH and CRITICAL only
                    'service.archived': {'Eq': ['false']}
                }
            }
        )
        unresolved_critical += len(findings['FindingIds'])

    evidence['controls']['guardduty'] = {
        'status': 'PASS' if detectors else 'FAIL',
        'detail': f"{len(detectors)} detector(s) active, {unresolved_critical} unresolved HIGH/CRITICAL findings",
        'unresolved_high_critical': unresolved_critical
    }

    # Control 5: VPC Flow Logs
    ec2 = boto3.client('ec2')
    flow_logs = ec2.describe_flow_logs(
        Filters=[{'Name': 'resource-type', 'Values': ['VPC']},
                 {'Name': 'flow-log-status', 'Values': ['ACTIVE']}]
    )['FlowLogs']
    evidence['controls']['vpc_flow_logs'] = {
        'status': 'PASS' if flow_logs else 'FAIL',
        'detail': f"{len(flow_logs)} active VPC flow log(s)",
        'active_flow_logs': len(flow_logs)
    }

    # Control 7: EBS encryption by default
    ebs_encryption = ec2.get_ebs_encryption_by_default()['EbsEncryptionByDefault']
    evidence['controls']['ebs_encryption_by_default'] = {
        'status': 'PASS' if ebs_encryption else 'FAIL',
        'detail': 'EBS encryption by default is enabled' if ebs_encryption else 'EBS encryption by default is NOT enabled'
    }

    # Control 8: S3 Block Public Access (account level)
    s3control = boto3.client('s3control')
    account_id = boto3.client('sts').get_caller_identity()['Account']
    try:
        pab = s3control.get_public_access_block(AccountId=account_id)['PublicAccessBlockConfiguration']
        all_blocked = all([pab['BlockPublicAcls'], pab['IgnorePublicAcls'],
                           pab['BlockPublicPolicy'], pab['RestrictPublicBuckets']])
        evidence['controls']['s3_block_public_access'] = {
            'status': 'PASS' if all_blocked else 'FAIL',
            'detail': 'All four S3 Block Public Access settings enabled' if all_blocked else 'One or more S3 Block Public Access settings not enabled',
            'configuration': pab
        }
    except Exception as e:
        evidence['controls']['s3_block_public_access'] = {'status': 'FAIL', 'detail': str(e)}

    # Upload evidence to S3 with Object Lock
    s3 = boto3.client('s3')
    evidence_key = f"daily/{evidence['collection_date']}/control-status.json"
    lock_until = datetime.now(timezone.utc) + timedelta(days=365)

    s3.put_object(
        Bucket="YOUR_EVIDENCE_BUCKET_NAME",
        Key=evidence_key,
        Body=json.dumps(evidence, indent=2),
        ContentType="application/json",
        ObjectLockMode="GOVERNANCE",
        ObjectLockRetainUntilDate=lock_until
    )

    # Alert if any control fails
    failed_controls = [k for k, v in evidence['controls'].items() if v['status'] == 'FAIL']
    if failed_controls:
        sns = boto3.client('sns')
        sns.publish(
            TopicArn='YOUR_ALERT_TOPIC_ARN',
            Subject=f'SOC2 Control Failure Detected — {evidence["collection_date"]}',
            Message=f'The following controls failed their daily check:nn{json.dumps(failed_controls, indent=2)}'
        )

    return {
        'statusCode': 200,
        'controls_checked': len(evidence['controls']),
        'controls_failed': len(failed_controls),
        'evidence_location': f"s3://YOUR_EVIDENCE_BUCKET_NAME/{evidence_key}"
    }

GitHub ایکشنز ایویڈنس ورک فلو

یہ ورک فلو روزانہ چلتا ہے اور ایسے شواہد حاصل کرتا ہے جو AWS APIs کے ذریعے خودکار نہیں ہوسکتے ہیں (GitHub لیول کنٹرول جیسے برانچ پروٹیکشن اسٹیٹس، حالیہ پل کی درخواست کی سرگرمی، CI پائپ لائن کے نتائج وغیرہ)۔ اسے اسی ثبوت کی بالٹی میں JSON فائل کے طور پر برآمد کریں۔

# .github/workflows/soc2-evidence.yml
name: SOC2 Evidence Collection
on:
  schedule:
    - cron: '0 1 * * *'   # 01:00 UTC daily (after the Lambda runs at 00:00)
  workflow_dispatch:        # Allow manual trigger when needed

permissions:
  contents: read

jobs:
  collect-github-evidence:
    name: Collect GitHub Control Evidence
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/evidence-collector
          aws-region: us-east-1

      - name: Collect branch protection status
        run: |
          DATE=$(date +%Y-%m-%d)
          mkdir -p evidence/github

          # Export branch protection rules for main
          curl -s -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" 
            "https://api.github.com/repos/${{ github.repository }}/branches/main/protection" 
            | jq '{
                date: "'$DATE'",
                enforce_admins: .enforce_admins.enabled,
                required_reviews: .required_pull_request_reviews.required_approving_review_count,
                required_status_checks: .required_status_checks.contexts,
                allow_force_pushes: .allow_force_pushes.enabled
              }' > evidence/github/branch-protection-$DATE.json

          echo "Branch protection evidence collected"
          cat evidence/github/branch-protection-$DATE.json

      - name: Upload evidence to S3
        run: |
          DATE=$(date +%Y-%m-%d)
          aws s3 sync evidence/ 
            s3://({{ secrets.SOC2_EVIDENCE_BUCKET }}/daily/)DATE/github/ 
            --no-progress
          echo "Evidence uploaded: s3://({{ secrets.SOC2_EVIDENCE_BUCKET }}/daily/)DATE/github/"

11-14 ہفتے: آڈیٹر کا انتخاب اور تیاری کا اندازہ

SOC2 آڈیٹر کا انتخاب کیسے کریں۔

صحیح آڈیٹر کا انتخاب زیادہ تر ٹیموں کے احساس سے زیادہ اہم ہے۔ SOC2 آڈٹ CPA فرموں کے ذریعے کیے جاتے ہیں، خاص طور پر وہ SOC رپورٹیں جاری کرنے کے لیے لائسنس یافتہ ہیں۔ صحیح کمپنی کو آپ کے سائز کی کلاؤڈ بیسڈ SaaS کمپنیوں کے ساتھ تجربہ ہے۔ غلط کمپنی ابتدائی مرحلے کے آغاز پر کارپوریٹ آڈٹ فریم ورک کا اطلاق کر سکتی ہے اور ایسے کنٹرولز کی بنیاد پر نتائج پیدا کر سکتی ہے جو صورتحال کے لیے مناسب نہیں ہیں۔

یہاں کیا تلاش کرنا ہے اور کس چیز کا خیال رکھنا ہے:

تجربہ برانڈ سے زیادہ اہم ہے۔

ایک بڑی بگ 4 فرم ضروری نہیں کہ 20 ملازمین والی SaaS کمپنی کے خصوصی بوتیک آڈیٹر سے بہتر ہو۔

مخصوص سوالات پوچھیں۔ "آپ نے پچھلے 12 مہینوں میں 10 سے 50 ملازمین والی SaaS کمپنیوں کے کتنے SOC2 آڈٹ مکمل کیے ہیں؟” آپ چاہتے ہیں کہ یہ معمول بن جائے، استثنا نہیں۔

تعمیل کے ٹولز سے واقفیت کو یقینی بنائیں

اگر آپ Vanta یا Drata کا استعمال کرتے ہیں، تو یقینی بنائیں کہ آپ کے آڈیٹرز کو ان پلیٹ فارمز کے ذریعے تیار کردہ ثبوتوں کا تجربہ ہے۔ کچھ آڈیٹرز خود شواہد اکٹھا کرنے کو ترجیح دیتے ہیں اور خودکار ثبوت کی برآمد سے واقف نہیں ہیں۔ آڈیٹرز جو آپ کے وانٹا شواہد پر بھروسہ نہیں کرتے وہ آپ سے ہر چیز کو دستی طور پر دوبارہ جمع کرنے کو کہیں گے۔

قسم II کی حقیقی قیمت کو سمجھیں۔

سیریز A SaaS کمپنی کے لیے، تین ماہ کے مشاہدے کی مدت کے ساتھ SOC2 قسم II کے آڈٹ کے لیے $15,000 سے $30,000 کی توقع کریں۔ ذیل کے تخمینے (10,000) کا اکثر مطلب ہوتا ہے کہ آڈیٹر جائزے کی گہرائی کو نظر انداز کر رہا ہے۔ چھوٹی کمپنیوں کے لیے، $50,000 سے اوپر کے اقتباسات کا عام طور پر مطلب یہ ہوتا ہے کہ کمپنی اسٹارٹ اپ معاہدوں پر انٹرپرائز قیمتوں کا اطلاق کر رہی ہے۔

اسی طرح کی کمپنیوں سے سفارشات حاصل کریں۔

اپنے آڈیٹر سے SaaS کمپنیوں سے دو سے تین حوالہ جات طلب کریں جنہوں نے پچھلے سال آڈٹ کیا تھا۔ اس حوالہ کو کال کریں اور سوالات پوچھیں۔ کیا آڈیٹر آپ کے کلاؤڈ انفراسٹرکچر کو سمجھتا ہے؟ کیا نتیجہ معقول تھا؟ جائزہ کے دوران مواصلت کیسی رہی؟

ذیل میں ایک جدول ہے جس میں کچھ چیزوں کا خلاصہ کیا گیا ہے جن پر توجہ دینے کی ضرورت ہے۔

معیاری آپ کو کیا تلاش کرنا چاہئے؟ ڈاکو
تجربہ 5 سالوں میں، ہر سال 20 سے زیادہ SaaS آڈٹ "ہم نے کئی SOC2 آڈٹ مکمل کر لیے ہیں” (مبہم)
آلے سے واقفیت ہم نے پہلے وانٹا/ڈراٹا شواہد کا جائزہ لیا ہے۔ خودکار ثبوت کو دستی طور پر دوبارہ جمع کیا جانا چاہیے۔
کمپنی کے سائز کے لیے موزوں ہے۔ میں نے آپ کی جیسی ہی کمپنیوں کا آڈٹ کیا ہے۔ صرف انٹرپرائز کلائنٹس حوالہ کے لیے درج ہیں۔
لاگت (قسم II) 20 افراد والی کمپنی کے لیے، (15K~)30K (10K یا زیادہ)50K سے کم بغیر کسی واضح وجہ کے
حوالہ جات آپ کال کرنے کے لیے اپنی SaaS کمپنی سے رابطہ کی معلومات فراہم کر سکتے ہیں۔ حوالہ فراہم کرنے سے قاصر

تیاری کا اندازہ کیسے چلایا جائے (مک آڈٹ)

تیاری کا اندازہ ایک حقیقی آڈٹ کا خود ساختہ ہے اور آڈیٹرز کے شرکت کرنے سے دو سے چار ہفتے پہلے چلایا جاتا ہے۔ مقصد یہ ہے کہ آڈیٹرز تلاش کرنے سے پہلے خلا کو تلاش کریں اور انہیں بند کریں۔ اس کی وجہ یہ ہے کہ فرضی آڈٹ میں پائے جانے والے خلاء کے لیے ایک ہفتے کے تدارک کا وقت درکار ہوتا ہے، جب کہ لائیو آڈٹ میں پائے جانے والے خلا کو مشروط رپورٹ اور جائزہ کی ضرورت ہوتی ہے۔

آپ تیاری کا جائزہ خود چلا سکتے ہیں یا اسے کرنے کے لیے کسی مشیر کی خدمات حاصل کر سکتے ہیں۔ ایک کنسلٹنٹ نقطہ نظر زیادہ قیمتی ہے کیونکہ ایک آزاد جائزہ لینے والا ان خلاء کو کھول سکتا ہے جن کو آپ نے عقلی بنایا ہے۔

طریقہ کار:

  1. مرحلہ 1: نیچے دی گئی چیک لسٹ میں موجود تمام کنٹرولز کا جائزہ لیں اور وہ ثبوت تیار کریں جو آپ کا آڈیٹر درخواست کرے گا۔

  2. مرحلہ 2: یہ کسی بھی کنٹرول میں ایک خلا ہے جو واضح، وقت پر مہر لگا ہوا ثبوت پیش نہیں کر سکتا۔ اسے دستاویز کریں۔

  3. مرحلہ 3: قسم کے لحاظ سے خلا کو ترجیح دیں۔ شواہد کے فرق (فعال کنٹرول کے بارے میں ثبوت غائب) ثبوت جمع کرنے کے بنیادی ڈھانچے میں ترمیم کی ضرورت ہے۔ کنٹرول گیپس (غیر لاگو کنٹرول) کے لیے انجینئرنگ کے کام کی ضرورت ہوتی ہے۔

  4. مرحلہ 4: اصل آڈیٹرز کو شامل کرنے سے پہلے کسی بھی خلا کو پُر کریں۔

کنٹرول مجھے ثبوت چاہیے۔ چیک کرنے کا طریقہ تیار ہیں؟
ایم ایف اے کا نفاذ IAM شناختی رپورٹ + SSO MFA پالیسی کا اسکرین شاٹ aws iam get-credential-report
CloudTrail فعال ہے۔ ٹریل اسٹیٹس + S3 ڈیلیوری کی تصدیق کریں۔ aws cloudtrail get-trail-status
گارڈ ڈیوٹی فعال ڈیٹیکٹر لسٹ + فاؤنڈری ریویو لاگ aws guardduty list-detectors
VPC فلو لاگز فعال بہاؤ لاگ فہرست + نمونہ لاگ اندراجات aws ec2 describe-flow-logs
سیکرٹس مینیجر سے راز خفیہ فہرست + روٹیشن پالیسی چیک کریں۔ aws secretsmanager list-secrets
EBS کی خفیہ کاری بذریعہ ڈیفالٹ اکاؤنٹ کی سطح کی خفیہ کاری ترتیب دیں۔ aws ec2 get-ebs-encryption-by-default
S3 عوامی رسائی کو مسدود کریں۔ اکاؤنٹ لیول پی اے بی کو کنفیگر کریں۔ aws s3control get-public-access-block
برانچ پروٹیکشن (کوئی ایڈمنسٹریٹر بائی پاس نہیں) GitHub برانچ پروٹیکشن API کا جواب GitHub API یا ترتیبات UI
CI کی سادہ سکیننگ GitHub ایکشنز اسکین دکھاتی ہوئی تاریخ چلاتی ہیں۔ GitHub آپریشن لاگ
واقعہ رسپانس رن بک مکمل شدہ رن بک + ڈیٹڈ ڈیسک پریکٹس نوٹ بک دستاویز کا جائزہ
رسائی کا جائزہ سہ ماہی جائزہ دستاویز جس میں مخصوص تبدیلیاں ہوں۔ دستاویز کا جائزہ
بیک اپ ٹیسٹ RDS بحالی لاگ + ڈیٹا کی تصدیق کے نتائج دستاویز کا جائزہ
مینجمنٹ لاگ کو تبدیل کریں۔ GitHub PR کی تاریخ + ArgoCD مطابقت پذیری کی تاریخ GitHub اور ArgoCD

ایک چیز جو زیادہ تر ٹیمیں چھوڑ دیتی ہیں: اپنے ثبوت کی بالٹی کے خلاف تیاری کا جائزہ چلائیں۔ ہم کسی بھی دن کے لیے روزانہ لیمبڈا ایکسپورٹ سے ثبوت حاصل کرتے ہیں اور اس بات کو یقینی بناتے ہیں کہ یہ مکمل، ٹائم اسٹیمپڈ، اور اس دن کے لیے کنٹرول کی حالت کو درست طریقے سے ظاہر کرتا ہے۔

اگر 14 دسمبر سے ثبوت کی فائل گارڈ ڈیوٹی کو PASS کے طور پر دکھاتی ہے، لیکن اصل میں اس دن گارڈ ڈیوٹی کو غیر فعال کر دیا گیا تھا، تو آڈیٹر آپ کے AWS اکاؤنٹ کے ریکارڈ میں تضاد پائے گا۔ یہ ایک کوالیفائنگ نتیجہ ہے۔

15-18 ہفتے: مشاہدے کی مدت

آڈیٹرز آپ کے کنٹرول کا کیسے مشاہدہ کرتے ہیں۔

SOC2 آڈیٹرز آپ کے دفتر کا جسمانی طور پر دورہ نہیں کرتے ہیں اور نہ ہی AWS کنسول کے اندر بیٹھتے ہیں تاکہ آپ کے بنیادی ڈھانچے کا حقیقی وقت میں مشاہدہ کیا جا سکے۔ ایک آڈٹ ایک دور دراز، دستاویز پر مبنی عمل ہے جو مکمل طور پر شواہد کے جائزے کے ذریعے کیا جاتا ہے۔

یہاں یہ ہے کہ یہ کس طرح کام کرتا ہے:

سب سے پہلے، آڈیٹر ثبوت کے لیے درخواستوں کی ایک فہرست فراہم کرتا ہے (عام طور پر ایک قسم II کے آڈٹ کے لیے 80 سے 150 آئٹمز)۔ ثبوت کو شیئرنگ پورٹل پر اپ لوڈ کریں (آپ کا آڈیٹر یہ فراہم کرے گا؛ یہ عام طور پر ایک محفوظ دستاویز شیئرنگ پلیٹ فارم ہوتا ہے)۔ آڈیٹر شواہد کا جائزہ لیتے ہیں، فالو اپ سوالات پوچھتے ہیں، اور ان علاقوں کی نشاندہی کرتے ہیں جہاں ثبوت غائب ہیں یا کنٹرولز جیسا کہ بیان کیا گیا ہے کام نہیں کر رہے ہیں۔

CloudTrail اور GuardDuty جیسے خودکار کنٹرولز کے لیے، ثبوت روزانہ Lambda کی برآمدات ہیں۔ آڈیٹرز مشاہدے کی مدت کے دوران روزانہ سنیپ شاٹس کے نمونے کا تصادفی طور پر معائنہ کرتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ کنٹرولز مسلسل فعال ہیں۔

دستی کنٹرولز، جیسے رسائی کے جائزے اور بیک اپ ٹیسٹنگ کے لیے، ثبوت وہ دستاویزات ہیں جو آپ ان کارروائیوں کو انجام دیتے وقت تیار کرتے ہیں۔

عملی مضمرات: آڈیٹر آپ کے ثبوت پر بھروسہ کر رہا ہے۔ یہی وجہ ہے کہ ثبوت کی بالٹی میں آبجیکٹ کو لاک کرنا ضروری ہے۔ یہ آڈیٹر کو ظاہر کرتا ہے کہ شواہد اس وقت بنائے گئے تھے جب اس کے تخلیق ہونے کا دعویٰ کیا جاتا ہے اور اس کے بعد سے اس میں کوئی ترمیم نہیں کی گئی ہے۔

مشاہدے کی مدت کے دوران آڈیٹر کے ذریعہ جائزہ لیا گیا۔

جو وہ چیک کرتے ہیں۔ کتنی بار وہ کیا تلاش کر رہے ہیں
CloudTrail لاگز ماہانہ آن سائٹ معائنہ IaC کو نظرانداز کرتے ہوئے دستی کنسول میں تبدیلیاں، لاگ فارورڈنگ میں فرق
گارڈ ڈیوٹی کے نتائج سہ ماہی خلاصہ جائزہ اعلی یا اہم نتائج دستاویزی SLA کے اندر حل نہیں ہوئے ہیں۔
کنکشن اسکریننگ مکمل ہو گئی۔ سہ ماہی سائیکل چیک کریں۔ ایسے جائزے جو چھوڑ دیے گئے ہیں اور جن کی رسائی عملے کے ٹرن اوور کے باوجود تبدیل نہیں ہوتی ہے۔
واقعے کے جواب کی جانچ سالانہ چیک کریں۔ مشاہدے کی مدت کے دوران کوئی ٹیبل ورزش نہیں کی گئی۔
ثبوت جمع کریں مسلسل کوریج کو یقینی بنائیں روزانہ شواہد کی برآمد میں فرق، مخصوص تاریخوں کے ثبوت غائب
مینجمنٹ لاگ کو تبدیل کریں۔ نمونہ PR/Sync ریکارڈ متعلقہ پل کی درخواستوں یا جائزوں کے بغیر تعیناتیاں

جو نتائج کو متحرک کرتا ہے۔

SOC2 کے نتائج آڈیٹر کے اس نتیجے کی دستاویز کرتے ہیں کہ مشاہدے کی مدت کے دوران کنٹرول مؤثر طریقے سے کام نہیں کرتے تھے۔ نتائج مشاہدات (معمولی مسائل جو آڈٹ کی رائے پر اثرانداز نہیں ہوتے) سے لے کر اہل رائے (بڑی ناکامیاں جن کے نتیجے میں اہل رپورٹ کی بجائے مستند رپورٹ ہوتی ہے) تک ہو سکتی ہے۔

آپ کے آڈٹ کے نظام الاوقات کو منظم کرنے کے لیے یہ سمجھنا کہ کیا نتائج کو متحرک کرتا ہے اور مشاہدے کے دورانیے کو کیا دوبارہ شروع کرتا ہے۔

کنٹرول خلا اس وقت ہوتا ہے جب مشاہدے کی مدت کے دوران مطلوبہ کنٹرولز کو نافذ نہیں کیا جاتا یا غیر فعال کر دیا جاتا ہے۔ دوسرے مہینے میں، اگر آپ کو پتہ چلتا ہے کہ پہلے تین ہفتوں کے دوران ایک IAM صارف پر MFA لاگو نہیں کیا گیا تھا، تو آپ کو قرارداد کو دستاویز کرنا چاہیے اور یہ ظاہر کرنا چاہیے کہ خلا کو بند کر دیا گیا ہے۔

آیا یہ مشاہدے کی مدت کو دوبارہ شروع کرتا ہے اس کا انحصار اس بات پر ہوگا کہ وقفہ کتنی دیر تک جاری رہا اور آڈیٹر کس طرح خطرے کا اندازہ لگاتا ہے۔ تاہم، 30 دنوں سے کم کا وقفہ جو کہ فوری طور پر درست اور دستاویز کیا جاتا ہے، عام طور پر گھڑی کو دوبارہ شروع نہیں کرتا ہے۔

ثبوت کا فرق یہ زیادہ سنجیدہ ہے۔ اگر روزانہ لیمبڈا ثبوت جمع کرنے والا دو ہفتوں تک ناکام ہو جاتا ہے اور کوئی ثبوت برآمد نہیں ہوتا ہے، تو دو ہفتوں کی مدت ہے جس میں کوئی دستاویزی ثبوت نہیں ہے کہ کنٹرولز کام کر رہے ہیں۔ آڈیٹر ان کنٹرولز کی تصدیق نہیں کر سکتے جس کے لیے وہ ثبوت نہیں دیکھ سکتے۔

شواہد کے خلا کو تقریباً ہمیشہ مشاہدے کی مدت میں توسیع کی ضرورت ہوتی ہے کیونکہ غیر ریکارڈ شدہ ادوار کے لیے سابقہ ​​طور پر ثبوت پیدا کرنے کا کوئی طریقہ نہیں ہے۔

عمل ناکام ہو گیا اس وقت ہوتا ہے جب دستی کنٹرول کو دستاویز کے مطابق لاگو نہیں کیا جاتا ہے۔ سب سے عام ایک نظر انداز رسائی کا جائزہ ہے۔ کنٹرول گیپس کی طرح، یہ مسائل عام طور پر گھڑی کو دوبارہ شروع کیے بغیر حل کیے جا سکتے ہیں اگر انہیں فوری طور پر دستاویز کیا جائے اور حل واضح ہو۔

تنقیدی بغیر پیچ شدہ CVEs یہ ایک خاص معاملہ ہے۔ اگر Trivy کسی پروڈکشن کنٹینر میں ایک CRITICAL خطرے کی نشاندہی کرتا ہے اور اسے دستاویزی تدارک کے SLA (عام طور پر کریٹیکل کے لیے 30 دن اور ہائی کے لیے 90 دن) سے زیادہ عرصے تک پیچ نہیں کیا گیا ہے، تو یہ آڈیٹر کے لیے اپنی رپورٹ میں نوٹ کرنے کے لیے قابلیت کی تلاش ہے۔

گھڑی کو دوبارہ شروع کیے بغیر وقفہ کو کیسے کم کیا جائے۔

اگر آپ اپنے مشاہدے کی مدت کے دوران کوئی فرق محسوس کرتے ہیں:

کنٹرول خلا کے لیے:

1. Fix the control immediately — don't wait
2. Document the fix: screenshot, PR link, or CLI command output with timestamp
3. Note the gap date range in your audit log: "Control gap: 2024-03-10 to 2024-03-14 (4 days). Root cause: [X]. Remediated: [Y]. No customer data accessed during gap period."
4. Notify your auditor proactively — they will find it anyway; proactive disclosure is better than defensive explanation
5. The observation period doesn't restart if the gap was short-lived and promptly remediated

ثبوت میں خلاء کی صورت میں:

1. Fix the evidence collection infrastructure immediately
2. Understand that you can't retroactively generate evidence for the gap period
3. The observation period for affected controls effectively restarts from the date evidence collection resumed
4. If the gap is early in your observation period, you may be able to extend the period rather than restart — discuss with your auditor

پرو تجاویز: ایک CloudWatch الارم سیٹ کریں جو اس وقت متحرک ہوتا ہے جب Lambda S3 کو شیڈول پر ثبوت فراہم کرنے میں ناکام ہو جاتا ہے۔ آڈٹ کے جائزے کے دوران بے نقاب ہونے کے 24 گھنٹوں کے اندر گمشدہ ثبوت کی فائلیں دریافت ہو جاتی ہیں۔

90 دن SOC2 ٹائم لائن کا خلاصہ

اہم توجہ مرکوز کلیدی ڈیلیوری ایبلز عام غلطیاں
1~2 رینج باؤنڈری ڈایاگرام، نیٹ ورک سیگمنٹیشن ٹیرافارم ترقی اور تیاری سمیت ضرورت سے زیادہ گنجائش
3~6 کنٹرول کرتا ہے 14 کنٹرولز کو لاگو کریں اور ثبوت جمع کریں۔ مشاہدے کی مدت شروع ہونے کے بعد کنٹرول شروع ہوتا ہے۔
7~10 ثبوت S3 ثبوت بالٹی، Lambda روزانہ کلکٹر، GitHub ایکشن ورک فلو ناگزیر خلا کے ساتھ دستی ثبوت جمع کرنا
11~14 تیاری فرضی آڈٹ، گیپ ریزولوشن، آڈیٹر کا انتخاب فرضی آڈٹ کو چھوڑ دیں۔
15~18 مشاہدہ روزانہ ثبوت، سہ ماہی جائزے، واقعہ کے جواب کی جانچ آڈٹ کے دوران شواہد کے خلا کو تلاش کرنا، پہلے نہیں۔

آگے کیا ہے؟

ہفتہ 1 سے شروع کریں۔ SOC2 کی حدود کی وضاحت کریں۔ ہمارے چار سوالوں کے فریم ورک کو اپنے انفراسٹرکچر کے ہر سسٹم پر لاگو کریں۔ Excalidraw میں خاکے بنائیں۔ دستاویز نیٹ ورک سیگمنٹیشن کنٹرولز۔

اس کے بعد ہم MFA اور CloudTrail سے شروع کرتے ہوئے ترتیب سے 14 کنٹرولز کو نافذ کرتے ہیں۔ یہ دو سب سے زیادہ عام طور پر آڈٹ کی ناکامی کا سبب بنتے ہیں اگر چھوٹ جاتے ہیں۔

پھر، مشاہدے کی مدت شروع ہونے سے پہلے اپنے ثبوت جمع کرنے کا بنیادی ڈھانچہ بنائیں۔ خودکار Lambda اور GitHub ایکشن ورک فلو ایک ہموار آڈٹ اور 60 دن کی توسیع کے درمیان فرق ہے۔

ایک چیز یاد رکھیں: SOC2 20% کنٹرول، 30% ثبوت، اور 50% مسلسل آپریشن ہے۔ جلدی شروع کریں۔ ہر چیز کو خودکار بنائیں۔ حقیقی آڈٹ کے لئے کال کرنے سے پہلے ایک فرضی آڈٹ چلائیں۔

وسائل

اس گائیڈ میں درج ذیل وسائل کا حوالہ دیا گیا ہے:

  • AICPA SOC2 کا جائزہ امریکی انسٹی ٹیوٹ آف CPAs سے سرکاری SOC2 دستاویز، بشمول ٹرسٹ سروس کے معیار

  • فخر کرنا – تعمیل آٹومیشن پلیٹ فارم جو AWS اور GitHub سے منسلک ہوتا ہے تاکہ شواہد اکٹھا کرنے اور کنٹرول کی حیثیت کو خودکار بنایا جا سکے۔

  • پاگل – ایک متبادل تعمیل آٹومیشن پلیٹ فارم جس میں ونٹا کی طرح کی فعالیت ہے۔

  • ٹریوی از ایکوا سیکیورٹی – اوپن سورس کنٹینر اور فائل سسٹم کی کمزوری اسکینر جو کنٹرول 10 میں استعمال ہوتا ہے۔

  • Excali ڈرا – SOC2 باؤنڈری ڈایاگرام بنانے کے لیے ایک مفت اور اوپن سورس ڈایاگرامنگ ٹول۔

  • AWS IAM شناختی مرکز کی دستاویزات – ایس ایس او اور ایم ایف اے کے نفاذ کے لیے سرکاری AWS دستاویزات

  • GitHub برانچ پروٹیکشن دستاویزات – برانچ کے تحفظ کے قواعد کو ترتیب دینے کے بارے میں سرکاری GitHub دستاویزات

  • ArgoCD دستاویزات – GitOps کی تعیناتی اور مطابقت پذیری کی تاریخ پر سرکاری ArgoCD دستاویزات

ایوبامی اڈیجومو سینئر پلیٹ فارم انجینئر اور FinOps ماہر۔ وہ SOC2 تعمیل انجینئرنگ، Kubernetes لاگت کی اصلاح، اور پلیٹ فارم انجینئرنگ کے بارے میں لکھتا ہے۔

Related Posts

اوپر تک سکرول کریں۔