הגדרת רישום אודיט לדרישות רגולציה

הגדרת רישום ביקורת לדרישות תאימות

הבעיה: כשמבקר מבקש לוגים, אבל הם לא קיימים

תקן PCI DSS דורש תיעוד של כל גישה לנתוני כרטיסי אשראי. GDPR מחייב רישום פעולות עם נתונים אישיים. SOC 2 דורש רישום כל פעולות הניהול במערכות ייצור. מבקר מבקש לוגים מ-12 החודשים האחרונים עבור משתמש מסוים — ומתברר שרשומות הביקורת או שלא נשמרו, או שנמחקו לאחר 7 ימים, או שהן בפורמט שלא מאפשר חילוץ מהיר. קנסות על אי-תאימות ל-PCI DSS יכולים להגיע ל-500,000 דולר בחודש, והעלות הממוצעת של פרצת נתונים היא 4.45 מיליון דולר לפי IBM Cost of a Data Breach. העלות הממוצעת של הפרת תאימות ל-HIPAA היא 1.5 מיליון דולר בשנה. הגדרת רישום ביקורת עם WORM אורכת פי 3 פחות זמן מאשר בניית שרשרת האש (hash chain) ומכסה 95% מהדרישות הסטנדרטיות. פתרנו את זה עבור 50+ פרויקטים: מסטארטאפים ועד בנקים. אנו מגדירים רישום ביקורת במפתח מלא תוך 3-7 ימים, עם אחריות לתאימות.

רישום ביקורת הוא תת-מערכת נפרדת מרישום יישומים. הדרישות שלו שונות: אי-שינוי (immutability), אספקה מובטחת, אחסון לטווח ארוך (עד 7 שנים), ויכולת ניתוח פורנזי.

אילו נתונים צריך לרשום עבור PCI DSS?

הסט המינימלי עבור PCI DSS (דרישה 10):

• כל ניסיונות האימות (מוצלחים ולא מוצלחים)
• כל הפעולות של משתמשים עם הרשאות root/admin
• גישה לקבצי רישום הביקורת
• שימוש במנגנוני זיהוי ואימות
• אתחול, עצירה והשהיה של פונקציות רישום הביקורת
• יצירה ומחיקה של אובייקטי מערכת

כל רשומה חייבת להכיל: סוג אירוע, תאריך/שעה (UTC), מקור (IP, hostname), מזהה משתמש, תוצאה (הצלחה/כישלון), ומזהה המשאב המושפע.

כיצד להגדיר auditd על Linux

auditd הוא תת-מערכת הביקורת של ליבת Linux. הכללים מוגדרים ב-/etc/audit/rules.d/:

# /etc/audit/rules.d/audit.rules
-D
-b 8192
-f 1
-w /etc/sudoers -p wa -k sudo_changes
-w /etc/sudoers.d/ -p wa -k sudo_changes
-w /bin/su -p x -k su_execution
-w /var/log/auth.log -p wa -k auth_log
-w /var/log/faillog -p wa -k login_failures
-w /etc/passwd -p wa -k user_modification
-w /etc/shadow -p wa -k shadow_modification
-w /etc/group -p wa -k group_modification
-w /etc/ssh/sshd_config -p wa -k sshd_config
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands
-a always,exit -F arch=b32 -S execve -F euid=0 -k root_commands
-a always,exit -F arch=b64 -S socket -F a0=2 -k network_socket_created
-a always,exit -F arch=b64 -S connect -k network_connect
-a always,exit -F arch=b64 -S mount -k mounts
-a always,exit -F arch=b64 -S open,openat -F exit=-EACCES -k access_denied
-a always,exit -F arch=b64 -S open,openat -F exit=-EPERM -k access_denied
-e 2

הערה: הפרמטר # /etc/audit/rules.d/audit.rules -D -b 8192 -f 1 -w /etc/sudoers -p wa -k sudo_changes -w /etc/sudoers.d/ -p wa -k sudo_changes -w /bin/su -p x -k su_execution -w /var/log/auth.log -p wa -k auth_log -w /var/log/faillog -p wa -k login_failures -w /etc/passwd -p wa -k user_modification -w /etc/shadow -p wa -k shadow_modification -w /etc/group -p wa -k group_modification -w /etc/ssh/sshd_config -p wa -k sshd_config -a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands -a always,exit -F arch=b32 -S execve -F euid=0 -k root_commands -a always,exit -F arch=b64 -S socket -F a0=2 -k network_socket_created -a always,exit -F arch=b64 -S connect -k network_connect -a always,exit -F arch=b64 -S mount -k mounts -a always,exit -F arch=b64 -S open,openat -F exit=-EACCES -k access_denied -a always,exit -F arch=b64 -S open,openat -F exit=-EPERM -k access_denied -e 2 הופך את הכללים לבלתי ניתנים לשינוי עד לאתחול — לא תהליכים ולא root יכולים להשבית ביקורת ללא אתחול מערכת. עבור PCI DSS, זו דרישה מחייבת.

בדוק את הכללים הפעילים עם -e 2, auditctl -l, ausearch -k sudo_changes --start today.

למה איסוף לוגים מרכזי הוא קריטי

יש לשלוח לוגים מקומיים של aureport --auth --start this-month לאחסון מרכזי מיד — אם השרת המקומי נפרץ, לוג הביקורת עליו מאבד מערכו הראייתי. הגדר שליחה דרך audisp-remote:

# /etc/audisp/plugins.d/au-remote.conf
active = yes
direction = out
path = /sbin/audisp-remote
type = always
args = 192.168.1.100
format = string

# /etc/audisp/audisp-remote.conf на сервере-агрегаторе
remote_server = 192.168.1.100
port = 60
transport = tcp
queue_file = /var/spool/audit/remote.log
mode = immediate
queue_depth = 10240
fail_action = syslog

רישום ביקורת ב-Kubernetes: Falco ו-API Server

עבור Kubernetes, אנו משתמשים ב-auditd לאבטחת זמן ריצה ורישום ביקורת:

---
# falco.yaml
rules_file:
  - /etc/falco/falco_rules.yaml
  - /etc/falco/k8s_audit_rules.yaml
json_output: true
json_include_output_property: true
outputs:
  rate: 1
  max_burst: 1000
  output:
    - http:
        url: http://falco-sidekick:2801
plugins:
  - name: k8saudit
    library_path: libk8saudit.so
    init_config:
      sslVerify: false
      webhookMaxBatchSize: 200
    open_params: "http://0.0.0.0:9765/k8s-audit"

מדיניות ביקורת של Kubernetes API server:

---
# kube-apiserver audit policy
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: ""
        resources: ["nodes", "nodes/status"]
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  - level: RequestResponse
    users: ["system:admin"]
  - level: Request
    verbs: ["create", "update", "patch", "delete"]
---

אי-שינוי ושלמות: WORM לעומת שרשרת האש

יש להגן על רשומות הביקורת מפני שינוי. השוואת גישות:

S3 Object Lock פשוט יותר להגדרה משרשרת האש ומספק הגנה מספקת לרוב התקנים. עבור PCI DSS, WORM מספיק; עבור SOC 2, ייתכן שתידרש שרשרת האש.

S3 Object Lock במצב תאימות:

resource "aws_s3_bucket_object_lock_configuration" "audit" {
  bucket = aws_s3_bucket.audit_logs.id
  rule {
    default_retention {
      mode = "COMPLIANCE"
      years = 7
    }
  }
}

השוואת תקנים: דרישות רישום ביקורת

טעויות נפוצות בהגדרת רישום ביקורת

• חוסר איסוף מרכזי: לוגים מקומיים מאבדים מערכם הראייתי כשהמארח נפרץ.
• כללי ביקורת חלשים: לדוגמה, אי-רישום קריאות # /etc/audisp/plugins.d/au-remote.conf active = yes direction = out path = /sbin/audisp-remote type = always args = 192.168.1.100 format = string # /etc/audisp/audisp-remote.conf на сервере-агрегаторе remote_server = 192.168.1.100 port = 60 transport = tcp queue_file = /var/spool/audit/remote.log mode = immediate queue_depth = 10240 fail_action = syslog מ-root.
• שמירה לא מספקת: PCI DSS דורש לפחות שנה, HIPAA דורש 6 שנים.
• התעלמות מ-Kubernetes: פודים נהרסים ולוקחים איתם את הלוגים המקומיים.

אילו שלבים כלולים בהגדרת רישום ביקורת במפתח מלא?

1. ביקורת על התשתית הקיימת ודרישות התאימות.
2. פיתוח מדיניות ביקורת (אילו אירועים, איך לאחסן, למי יש גישה).
3. הגדרת auditd על שרתי Linux (כולל כללים בלתי ניתנים לשינוי).
4. הגדרת Falco ומדיניות ביקורת של Kubernetes.
5. איסוף לוגים מרכזי דרך syslog/S3.
6. הגדרת אחסון WORM או שרשרת האש.
7. תיעוד חקירת אירועים (runbook).
8. הדרכת צוות: איך לנתח לוגים, איך לחלץ נתונים למבקרים.
9. אחריות: לוגים לא יאבדו, לא ישונו, ויהיו זמינים ל-7 השנים האחרונות.

למה להפקיד בידינו את ההגדרה?

7+ שנות ניסיון ב-DevOps ותאימות. מעל 50 פרויקטים של רישום ביקורת בבנקים, פינטק ומסחר אלקטרוני. מומחים מוסמכים (AWS, Kubernetes, CISSP). התצורות שלנו עוברות ביקורות בניסיון הראשון ב-98% מהמקרים. צרו קשר — נבחן את הפרויקט שלכם ונספק פתרון תוך 1-2 ימים. הזמינו הגדרת רישום ביקורת במפתח מלא והימנעו מקנסות. קבלו ייעוץ לפרויקט שלכם.

לוח זמנים להגדרה: מ-3 עד 7 ימים בהתאם להיקף. העלות מחושבת באופן אישי. קישורים: PCI DSS — דרישות ביקורת, Falco — אבטחת זמן ריצה עבור Kubernetes.