SOC 2 στο AWS: ένα τεχνικό checklist για startups

Δεν είναι συμβουλή ελέγχου. SOC 2 report εκδίδει μόνο αδειοδοτημένη εταιρεία ορκωτών λογιστών (CPA firm), και ο auditor σας αποφασίζει ποια στοιχεία καλύπτουν κάθε control. Εδώ μιλάμε για το τεχνικό κομμάτι: τι να στήσετε στο AWS ώστε ο έλεγχος να κυλήσει ομαλά.

Το SOC 2 δεν είναι πιστοποιητικό. Είναι μια έκθεση διαβεβαίωσης: ένας ανεξάρτητος ελεγκτής εξετάζει τα controls σας με βάση τα Trust Services Criteria του AICPA και γράφει τη γνώμη του. Για ένα startup που πουλάει σε μεγαλύτερες εταιρείες, αυτή η έκθεση είναι η διαφορά ανάμεσα σε ένα questionnaire 200 ερωτήσεων και στο «ορίστε το SOC 2 μας, και μερικές διευκρινίσεις».

Τα περισσότερα controls που ελέγχονται είναι οργανωτικά: πολιτικές, onboarding, έλεγχοι ιστορικού, εκτίμηση κινδύνου. Ένα μεγάλο κομμάτι όμως ζει μέσα στο cloud σας, και αυτό καταλήγει στους engineers. Αυτό είναι το checklist που χρησιμοποιούμε για το AWS.

Το SOC 2 σε δύο λεπτά: Type I, Type II και τα κριτήρια

Ένα Type I report λέει ότι τα controls σας είναι σωστά σχεδιασμένα σε μια συγκεκριμένη ημερομηνία. Ένα Type II λέει ότι, επιπλέον, λειτούργησαν αποτελεσματικά σε βάθος χρόνου, κάτι που ο auditor ελέγχει παίρνοντας δείγματα από όλη την περίοδο.

Οι πελάτες συνήθως θέλουν Type II, γιατί δείχνει ότι τα controls δουλεύουν στην πράξη και όχι μόνο στα χαρτιά. Πολλά startups κάνουν πρώτα Type I για να έχουν κάτι να δείξουν, και μετά ξεκινούν την περίοδο παρατήρησης για το Type II. Τη διάρκειά της τη συμφωνείτε με τον auditor· στις πρώτες εκθέσεις είναι συχνά μικρότερη απ' ό,τι στις επόμενες.

Τα κριτήρια προέρχονται από τα 2017 Trust Services Criteria του AICPA (με τα points of focus αναθεωρημένα το 2022) και καλύπτουν πέντε κατηγορίες:

• Security (τα «common criteria»): υποχρεωτική σε κάθε SOC 2 report.
• Availability: διαθεσιμότητα, χωρητικότητα, backups και ανάκαμψη.
• Processing integrity: η επεξεργασία είναι πλήρης, ακριβής και έγκαιρη.
• Confidentiality: προστασία των εμπιστευτικών πληροφοριών.
• Privacy: τα προσωπικά δεδομένα διαχειρίζονται όπως έχετε δεσμευτεί.

Τα περισσότερα startups ξεκινούν μόνο με Security, ή Security και Availability, και προσθέτουν κατηγορίες όταν το ζητήσουν πελάτες. Κάτι που αξίζει να παρακολουθείτε: τον Οκτώβριο του 2026 το AICPA δημοσίευσε exposure draft με ανανεωμένα κριτήρια για το 2027. Είναι πρόταση σε δημόσια διαβούλευση, όχι σε ισχύ, οπότε χτίστε με βάση τα τρέχοντα κριτήρια και ρωτήστε τον auditor πότε θα σας αφορά η αλλαγή.

Shared responsibility: το SOC report του AWS δεν είναι δικό σας

Το AWS έχει το δικό του SOC 2 report, αλλά αυτό καλύπτει τα controls του AWS, όχι τη δική σας παραμετροποίηση. Ο auditor θα ελέγξει πώς στήσατε και πώς λειτουργείτε τους λογαριασμούς σας.

Το AWS το περιγράφει στο shared responsibility model: το AWS ασφαλίζει την υποδομή («security of the cloud»), εσείς ό,τι χτίζετε πάνω της («security in the cloud»). Τα φυσικά controls των data centers τα κληρονομείτε πλήρως. Το patching, το configuration management και η εκπαίδευση είναι κοινή ευθύνη. Τα IAM policies, οι ρυθμίσεις των S3 buckets και η εφαρμογή σας είναι αποκλειστικά δικά σας.

Στην πράξη, ο auditor συνήθως αντιμετωπίζει το AWS ως subservice organization και εξαιρεί τα controls του από τη δική σας έκθεση, στηριζόμενος στο report του AWS. Τα SOC 1 και SOC 2 reports του AWS τα κατεβάζετε από το AWS Artifact με NDA· κρατήστε αντίγραφο στον φάκελο προμηθευτών, γιατί θα σας ρωτήσουν πώς το αξιολογήσατε. Το report του AWS απαριθμεί και τα controls που περιμένει να λειτουργούν οι πελάτες. Διαβάστε τη λίστα· είναι καλός έλεγχος πάνω σε αυτό το checklist.

Τα τεχνικά controls, αντιστοιχισμένα στο AWS

Κάθε σημείο παρακάτω αντιστοιχεί σε ένα ή περισσότερα common criteria. Η λίστα του auditor σας θα είναι διατυπωμένη αλλιώς, αλλά αυτά είναι που θα ζητήσει να δει.

1. Δομή λογαριασμών και guardrails: AWS Organizations και SCPs

Ξεχωρίστε την παραγωγή από όλα τα υπόλοιπα και κάντε το security baseline αδύνατο να απενεργοποιηθεί. Χρησιμοποιήστε AWS Organizations με τουλάχιστον management account, log-archive account, security account και ξεχωριστά workload accounts για production και non-production. Τη δομή την περιγράφουμε στο AWS Organizations από την πρώτη μέρα.

Μετά προσθέστε service control policies που εμποδίζουν οποιονδήποτε, ακόμη και τους admins ενός account, να κλείσει τα controls στα οποία βασίζεται ο auditor:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectSecurityBaseline",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "cloudtrail:UpdateTrail",
        "config:StopConfigurationRecorder",
        "config:DeleteConfigurationRecorder",
        "config:DeleteDeliveryChannel",
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromAdministratorAccount",
        "securityhub:DisableSecurityHub",
        "organizations:LeaveOrganization"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/SecurityBreakGlass"
        }
      }
    }
  ]
}

Τα SCPs δεν εφαρμόζονται στο management account, οπότε κρατήστε τα workloads έξω από αυτό και κλειδώστε το χωριστά.

2. Identity: IAM Identity Center με MFA

Κάθε άνθρωπος έχει ακριβώς μία ταυτότητα, με υποχρεωτικό MFA. Συνδέστε το IAM Identity Center με τον identity provider σας (Google Workspace, Entra ID, Okta), δώστε permission sets ανά account και καταργήστε τους IAM users με μόνιμα access keys. Τα βήματα είναι στον οδηγό για το IAM Identity Center.

• Root user σε κάθε account: hardware MFA, χωρίς access keys, credentials φυλαγμένα offline.
• Access reviews κάθε τρίμηνο: εξαγωγή του ποιος έχει ποιο permission set, έγκριση από υπεύθυνο, κρατάτε το αρχείο.
• Offboarding: η απενεργοποίηση στον identity provider κόβει την πρόσβαση στο AWS την ίδια μέρα. Οι auditors παίρνουν δείγμα αποχωρήσεων και ελέγχουν τις ώρες.
• Το CI/CD χρησιμοποιεί OIDC roles αντί για αποθηκευμένα keys· δείτε το GitHub Actions στο AWS με OIDC.

3. Audit logging: CloudTrail σε όλο τον οργανισμό

Ένα organization trail, σε όλες τις regions, με παράδοση στο log-archive account και log file validation ενεργό. Έτσι έχετε ένα αρχείο κάθε API call που δείχνει αν κάποιος το πείραξε, και αυτό θα χρειαστεί τόσο ο auditor όσο και κάθε διερεύνηση incident.

resource "aws_cloudtrail" "org" {
  name                          = "org-trail"
  s3_bucket_name                = aws_s3_bucket.cloudtrail.id
  is_organization_trail         = true
  is_multi_region_trail         = true
  include_global_service_events = true
  enable_log_file_validation    = true
  kms_key_id                    = aws_kms_key.cloudtrail.arn
}

Βάλτε S3 Object Lock ή αυστηρό bucket policy στο bucket των logs, ώστε κανείς σε workload account να μην μπορεί να σβήσει ιστορικό. Ορίστε retention σύμφωνα με την πολιτική σας, και αν διαχειρίζεστε προσωπικά δεδομένα πολιτών της ΕΕ, κρατήστε τα logs σε ευρωπαϊκές regions, όπως εξηγούμε στον οδηγό για GDPR και logging.

4. Παρακολούθηση ρυθμίσεων: AWS Config και Security Hub

Οι auditors θέλουν απόδειξη ότι τα λάθος configurations εντοπίζονται και διορθώνονται, συνεχώς. Το AWS Config κρατά ιστορικό ρυθμίσεων κάθε πόρου· το Security Hub CSPM με το AWS Foundational Security Best Practices standard τις ελέγχει απέναντι σε ένα αναγνωρισμένο baseline και βαθμολογεί κάθε account. Ενεργοποιήστε και τα δύο σε όλο τον οργανισμό από το security account, ως delegated administrator.

Το νεότερο AWS Security Hub, γενικά διαθέσιμο από τον Δεκέμβριο του 2025, κάθεται από πάνω και συσχετίζει findings από Security Hub CSPM, GuardDuty και Inspector. Όποιο κι αν χρησιμοποιήσετε, το control είναι ίδιο: τα findings αξιολογούνται, ανατίθενται και κλείνουν, και μπορείτε να δείξετε την τάση.

5. Ανίχνευση απειλών: GuardDuty

Ενεργοποιήστε το GuardDuty σε κάθε account και κάθε region που χρησιμοποιείτε, με διαχείριση από το security account και auto-enable για νέα accounts. Στείλτε τα findings υψηλής σοβαρότητας εκεί που πάνε και τα on-call alerts. Ο auditor θα διαλέξει ένα finding και θα ρωτήσει ποιος το είδε και πότε.

6. Κρυπτογράφηση: KMS at rest, TLS in transit

• Ενεργοποιήστε EBS encryption by default σε κάθε region και κάθε account.
• Κρυπτογραφήστε RDS, S3, DynamoDB και backups με KMS keys. Τα customer-managed keys σας επιτρέπουν να ξεχωρίσετε ποιος χρησιμοποιεί ένα key από ποιος το διαχειρίζεται.
• TLS παντού: πιστοποιητικά ACM σε load balancers και CloudFront, και bucket policy που απορρίπτει αιτήματα χωρίς TLS.
• S3 Block Public Access σε επίπεδο account, ώστε ένα δημόσιο bucket να απαιτεί συνειδητή εξαίρεση.

7. Backups και δοκιμές restore

Τα backups είναι control της Availability, και οι auditors ζητούν όλο και συχνότερα απόδειξη ότι γίνονται restores, όχι μόνο backup jobs. Χρησιμοποιήστε AWS Backup plans με αντίγραφα σε ξεχωριστό account, και το AWS Backup restore testing για αυτόματα restores σε πρόγραμμα. Καταγράψτε πόσο κράτησε το restore και συγκρίνετέ το με τον χρόνο ανάκαμψης που υπόσχεστε στους πελάτες.

8. Change management: pull requests και infrastructure as code

Το control του change management αποδεικνύεται πιο εύκολα όταν κάθε αλλαγή περνά από το Git. Οι αλλαγές σε κώδικα και υποδομή γίνονται με pull request, τις κάνει review κάποιος άλλος από τον συγγραφέα, περνούν από CI και κάνουν deploy μέσω pipeline, όχι από ένα laptop.

• Branch protection στο main: υποχρεωτικό review, υποχρεωτικά status checks, όχι force push.
• Terraform για όλη την υποδομή, με state οργανωμένο ανά περιβάλλον (δείτε πώς οργανώνουμε το Terraform state).
• Δικαίωμα αλλαγών από το console στην παραγωγή μόνο μέσω break-glass role, με alert σε κάθε χρήση.
• Επείγουσες αλλαγές επιτρέπονται, αλλά γίνεται review εκ των υστέρων και συνδέονται με το incident.

Τα στοιχεία για τον έλεγχο είναι τότε απλώς τα merged pull requests για ένα δείγμα deployments, που το Git ήδη κρατά.

9. Διαχείριση ευπαθειών: Inspector και dependency scanning

Το Amazon Inspector σκανάρει συνεχώς EC2 instances, container images στο ECR και Lambda functions για γνωστές ευπάθειες και έκθεση στο δίκτυο. Προσθέστε dependency scanning στο CI (Dependabot ή κάτι αντίστοιχο) για τον κώδικα της εφαρμογής. Μετά γράψτε μια πολιτική με προθεσμίες διόρθωσης ανά σοβαρότητα και κάντε ορατά όσα έχουν καθυστερήσει. Τις προθεσμίες τις ορίζετε εσείς· ο auditor ελέγχει αν τις τηρείτε.

10. Logging, alerting και απόκριση σε incidents

Κεντρικά application logs με ορισμένο retention, alerts που φτάνουν σε άνθρωπο, και μια γραπτή διαδικασία για incidents που την έχετε χρησιμοποιήσει στ' αλήθεια. Αν δεν έχετε ακόμη, ξεκινήστε από το πρότυπο incident response runbook μας. Κρατήστε αρχείο incidents και postmortems ακόμη και για τα μικρά· ένα άδειο αρχείο για ολόκληρο χρόνο είναι λιγότερο πειστικό από μερικά μικρά incidents που χειριστήκατε σωστά.

11. Διαχείριση προμηθευτών

Καταγράψτε κάθε προμηθευτή που αγγίζει δεδομένα πελατών ή την παραγωγή (AWS, CI provider, error tracking, email, πληρωμές), τι δεδομένα κρατά ο καθένας και το δικό του SOC 2 ή ISO 27001. Ελέγξτε τη λίστα μία φορά τον χρόνο. Είναι κυρίως ένα spreadsheet, αλλά είναι control, και ελέγχεται.

Αντιστοίχιση controls και στοιχείων

Συλλέξτε τα στοιχεία ως φυσικό αποτέλεσμα του τρόπου που δουλεύετε, όχι σε πανικό λίγο πριν κλείσει η περίοδος ελέγχου.

Πού ταιριάζουν τα εργαλεία compliance automation

Εργαλεία όπως Vanta, Drata και Secureframe συνδέονται με read-only πρόσβαση στο AWS, στον identity provider και στο Git, τρέχουν συνεχείς ελέγχους και πακετάρουν τα στοιχεία για τον auditor. Δίνουν επίσης πρότυπα πολιτικών και παρακολουθούν το ανθρώπινο κομμάτι: εκπαίδευση, ελέγχους ιστορικού, κρυπτογράφηση laptops.

Γλιτώνουν πραγματικό χρόνο στη συλλογή στοιχείων, και από την εμπειρία μας αξίζουν για τα περισσότερα startups που πάνε για πρώτο Type II. Αυτό που δεν κάνουν είναι να διορθώσουν οτιδήποτε. Ένα dashboard γεμάτο κόκκινα checks θέλει ακόμη κάποιον να αναδιοργανώσει τα accounts, να γράψει τα SCPs και να στήσει τα backup plans. Διαλέξτε εργαλείο με βάση τα integrations με το stack σας και τον auditor σας, και μετά κάντε την τεχνική δουλειά που περιγράψαμε.

Αν σκοπεύατε να χρησιμοποιήσετε το AWS Audit Manager: το AWS το έκλεισε σε νέους πελάτες στις 30 Απριλίου 2026 και παραπέμπει στα AWS Config conformance packs. Η ίδια σελίδα σημειώνει ότι δεν υπάρχει conformance pack αντίστοιχο με το SOC 2 framework του, οπότε υπολογίστε σε Security Hub CSPM, Config rules και είτε ένα εξωτερικό εργαλείο είτε δικά σας exports.

Αξιοποιήστε τη δουλειά για NIS2 και GDPR

Τα περισσότερα από αυτά τα controls επικαλύπτονται με άλλα πλαίσια. Αν πουλάτε και σε ρυθμιζόμενους κλάδους στην ΕΕ, το checklist για NIS2 στο AWS αντιστοιχίζει τα ίδια δομικά στοιχεία στο άρθρο 21 και προσθέτει όσα δεν καλύπτει το SOC 2, όπως τις προθεσμίες αναφοράς incidents σε 24 και 72 ώρες.

Μια λογική σειρά δουλειάς

1. Ορίστε το scope με τον auditor: ποια συστήματα και ποια κριτήρια.
2. Φτιάξτε πρώτα το identity: Identity Center, MFA, όχι μόνιμα keys.
3. Ενεργοποιήστε το baseline σε όλο τον οργανισμό: CloudTrail, Config, Security Hub CSPM, GuardDuty, Inspector, προστατευμένα με SCPs.
4. Περάστε όλες τις αλλαγές σε pull requests και Terraform.
5. Στήστε backup plans και κάντε την πρώτη δοκιμή restore.
6. Γράψτε τις πολιτικές, συνδέστε το εργαλείο συλλογής στοιχείων και ξεκινήστε την περίοδο παρατήρησης.

Αν θέλετε μια εξωτερική ματιά στο πού βρίσκεται το AWS σας πριν σας τη δώσει ο auditor, ένα cloud audit αντιστοιχίζει τους λογαριασμούς σας σε αυτά τα controls και σας δίνει λίστα κενών με προτεραιότητες. Κι αν μετά δεν έχει κανείς στην ομάδα χρόνο να κρατά το baseline, το managed DevOps μας το κρατά σε λειτουργία και φροντίζει να ρέουν τα στοιχεία σε όλη την περίοδο ελέγχου.

Συχνές ερωτήσεις

Ποια είναι η διαφορά ανάμεσα σε SOC 2 Type I και Type II;

Το Type I αξιολογεί αν τα controls σας είναι σωστά σχεδιασμένα σε μια συγκεκριμένη ημερομηνία. Το Type II ελέγχει επιπλέον αν λειτούργησαν αποτελεσματικά σε μια περίοδο, με τον auditor να παίρνει δείγματα από όλο το διάστημα. Οι περισσότεροι μεγάλοι πελάτες ζητούν Type II· πολλά startups κάνουν πρώτα Type I για να έχουν κάτι να δείξουν νωρίτερα.

Αν είμαστε στο AWS, είμαστε συμμορφωμένοι με το SOC 2;

Όχι. Το SOC 2 report του AWS καλύπτει τα δικά του controls, όπως τη φυσική ασφάλεια των data centers. Ο auditor σας ελέγχει πώς ρυθμίζετε και λειτουργείτε τους λογαριασμούς σας: identity και MFA, logging, κρυπτογράφηση, backups, change management και ευπάθειες. Το report του AWS από το AWS Artifact βοηθά στην αξιολόγηση προμηθευτή, αλλά δεν αντικαθιστά τα δικά σας controls.

Ποιες υπηρεσίες AWS χρειαζόμαστε για SOC 2;

Δεν υπάρχει υποχρεωτική λίστα, αλλά ένα τυπικό baseline είναι AWS Organizations με SCPs, IAM Identity Center με MFA, CloudTrail σε όλο τον οργανισμό, AWS Config, Security Hub CSPM, GuardDuty, Amazon Inspector, κρυπτογράφηση με KMS και AWS Backup με restore testing. Μαζί με change management μέσω pull requests, καλύπτουν τα περισσότερα controls στο cloud.

Χρειαζόμαστε Vanta ή Drata για SOC 2;

Όχι απαραίτητα. Μπορείτε να περάσετε τον έλεγχο με spreadsheets και χειροκίνητα exports. Τα εργαλεία compliance automation γλιτώνουν χρόνο συλλέγοντας στοιχεία συνεχώς και δίνοντας πρότυπα πολιτικών, κάτι που βοηθά κυρίως στο πρώτο Type II. Δεν διορθώνουν όμως ρυθμίσεις, οπότε χρειάζεστε ακόμη κάποιον να χτίσει τα controls στο AWS.