אימות רשת ארגונית: Kerberos SSO והתקנת KDC

אימות מרכזי עם Kerberos: פריסת KDC ושילוב

אתה מנהל רשת של 200+ צמתים שבהם שירותים מתקשרים דרך SSH ו-HTTP, ומשתמשים נכנסים לתריסר מערכות עם סיסמאות שונות—או גרוע מכך, הם משתמשים באותה סיסמה בכל מקום. אנו פותרים בעיה זו עם Kerberos: כניסה יחידה (SSO) ללא העברת סיסמאות ברשת ואימות הדדי של שירותים באמצעות כרטיסים. בהתבסס על ניסיוננו ב-50+ פרויקטים, אנו מבטיחים תצורה עמידה לתקלות שעובדת שנים ללא כשלים. לדוגמה, עבור לקוח פינטק, פרסנו MIT Kerberos על 300 פודים של K8s עם שילוב דרך רשת שירותים של Istio, והפחתנו את זמן האימות ב-80% בהשוואה לשיטות מבוססות סיסמה מסורתיות.

אבל פריסת MIT Kerberos בסביבת ייצור אינה פשוטה כמו apt install krb5-kdc וחצי שעה. קל לאבד שבוע אם לא מתחשבים בניואנסים בסנכרון זמן, DNS וסיבוב מפתחות. קבל ייעוץ—נעריך את הפרויקט שלך ביום אחד. עלויות טיפוסיות מתחילות ב-$5,000 לפריסות קטנות, וחוסכות עד $20,000 בשנה בהפחתת כרטיסי helpdesk.

בעיות ש-Kerberos פותר

זמני השרתים נסחפים. Kerberos סובל הפרש של לא יותר מ-5 דקות בין KDC ללקוח. אם NTP לא מוגדר או ש-ntpd קורס, האימות מתחיל להיכשל עם KRB5KRB_AP_ERR_SKEW. תרחיש טיפוסי: הכל עובד, ואז אחרי שבוע על שרת אחד הסחיפה מגיעה לסף—ומתחילות תלונות על 'לא ניתן להיכנס'. /etc/krb5.conf על הלקוח מואשם לעיתים קרובות ראשון, אבל הבעיה נמצאת במקום אחר.

DNS לא מוגדר עבור Kerberos. ה-KDC מתגלה דרך רשומות SRV של _kerberos._tcp.REALM. אם DNS לא משרת רשומות אלה, לקוחות חייבים לקודד את ה-KDC ב-krb5.conf, מה ששובר את ה-failover. בנוסף, ה-DNS ההפוך עבור ה-KDC חייב לפתור בדיוק לשם המארח שעבורו הונפק ה-keytab—אי התאמה גורמת ל-KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN בעת קבלת כרטיס שירות.

קבצי keytab לא מסובבים. עקרונות שירות עבור HTTP, LDAP, host—לכולם יש סיסמאות שנוצרו במהלך ההתקנה הראשונית. אחרי שנה, כשצריך לעדכן מפתחות, אתה מגלה שההליך לא מתועד, וחצי מהשירותים יקרסו מיד אחרי ktpass ללא הפעלה מחדש. מעל 90% מכשלי האימות נובעים מסחיפת זמן או keytab שפג תוקפו.

איך לבחור אלגוריתמי הצפנה?

לפי תיעוד MIT Kerberos, AES256 חזק פי 10 מיליון מ-RC4, מה שהופך אותו לבטוח פי 10^7. צפנים חלשים צריכים להיות מושבתים דרך supported_enctypes על ה-KDC ו-allow_weak_crypto = false על הלקוחות.

איך להגדיר רשומות DNS SRV עבור Kerberos?

לצורך עמידות לתקלות, נדרשות רשומות SRV בצורה _kerberos._tcp.REALM, המצביעות על כל ה-KDCs (ראשי ומשני). דוגמה ב-BIND:

_kerberos._tcp.corp.example.com. IN SRV 0 100 88 kdc-master.corp.example.com.
_kerberos._tcp.corp.example.com. IN SRV 0 100 88 kdc-slave1.corp.example.com.

רשומת A עבור כל KDC היא גם חובה. ללא DNS SRV, לקוחות לא יכולים לבצע failover אוטומטי ל-replica כשהראשי נופל.

איך אנו מתכננים ארכיטקטורת KDC

לצורך עמידות לתקלות, נדרשים לפחות KDC ראשי אחד ו-KDC משני אחד (replica). MIT Kerberos משתמש ב-_kerberos._tcp.corp.example.com. IN SRV 0 100 88 kdc-master.corp.example.com. _kerberos._tcp.corp.example.com. IN SRV 0 100 88 kdc-slave1.corp.example.com. לשכפול מסד נתונים:

# /etc/krb5.conf (фрагмент клиента)
[libdefaults]
  default_realm = CORP.EXAMPLE.COM
  dns_lookup_realm = false
  dns_lookup_kdc = true
  ticket_lifetime = 10h
  renew_lifetime = 7d
  forwardable = true
  clockskew = 300

[domain_realm]
  .corp.example.com = CORP.EXAMPLE.COM
  corp.example.com = CORP.EXAMPLE.COM

# /etc/krb5kdc/kdc.conf (на KDC)
[kdcdefaults]
  kdc_listen = 88
  kdc_tcp_listen = 88

[realms]
  CORP.EXAMPLE.COM = {
    acl_file = /etc/krb5kdc/kadm5.acl
    key_stash_file = /etc/krb5kdc/.k5.CORP.EXAMPLE.COM
    max_life = 10h 0m 0s
    max_renewable_life = 7d 0h 0m 0s
    master_key_type = aes256-cts
    supported_enctypes = aes256-cts:normal aes128-cts:normal
  }

שכפול למשני מוגדר דרך kpropd, שרץ מ-cron על הראשי כל 15 דקות. לשכפול אוטומטי, ל-Heimdal יש # /etc/krb5.conf (фрагмент клиента) [libdefaults] default_realm = CORP.EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true ticket_lifetime = 10h renew_lifetime = 7d forwardable = true clockskew = 300 [domain_realm] .corp.example.com = CORP.EXAMPLE.COM corp.example.com = CORP.EXAMPLE.COM מובנה, אבל MIT דורש סקריפט. הגדרת Kerberos נכונה כוללת סנכרון זמן והגדרת DNS כדי להימנע ממלכודות נפוצות.

איך להימנע משגיאות סנכרון זמן

ב-70% מהמקרים, בעיות Kerberos נגרמות מסחיפת זמן. הגדר NTP על כל הצמתים עם התראות אם הסחיפה עולה על דקה. השתמש במאגר של שרתים מדויקים (NTP Pool Project) ובדוק את # /etc/krb5kdc/kdc.conf (на KDC) [kdcdefaults] kdc_listen = 88 kdc_tcp_listen = 88 [realms] CORP.EXAMPLE.COM = { acl_file = /etc/krb5kdc/kadm5.acl key_stash_file = /etc/krb5kdc/.k5.CORP.EXAMPLE.COM max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s master_key_type = aes256-cts supported_enctypes = aes256-cts:normal aes128-cts:normal } על הלקוחות.

שילוב עם LDAP ו-Active Directory

בסביבות ארגוניות, Kerberos כמעט תמיד עובד לצד LDAP—או עם OpenLDAP דרך ה-backend של kprop (כך שמסד הנתונים של העקרונות נשמר ישירות בעץ ה-LDAP) או עם Microsoft AD, שבו Kerberos הוא פרוטוקול טבעי.

בעת שילוב עם AD דרך hpropd (החבילה timedatectl), קריטי להגדיר krb5-kdc-ldap ב-realm join, אחרת SSSD יתנגש עם פותר ה-KDC של המערכת. כמו כן, כפה AES256 והשבת RC4:

# Проверить поддерживаемые enctypes для принципала
kvno -e aes256-cts-hmac-sha1-96 host/[email protected]

# Выдать keytab для HTTP-сервиса
kadmin -q "addprinc -randkey HTTP/[email protected]"
kadmin -q "ktadd -k /etc/webapp.keytab HTTP/[email protected]"

עבור יישומי web על nginx או Apache עם realmd / krb5_use_kdcinfo = false, ה-keytab מורכב בספריית השירות עם הרשאות /etc/sssd/sssd.conf ובעלים # Проверить поддерживаемые enctypes для принципала kvno -e aes256-cts-hmac-sha1-96 host/[email protected] # Выдать keytab для HTTP-сервиса kadmin -q "addprinc -randkey HTTP/[email protected]" kadmin -q "ktadd -k /etc/webapp.keytab HTTP/[email protected]" . בעת עדכון ה-keytab, מפתחות ישנים צריכים להישאר בקובץ—mod_auth_gssapi מוסיף גרסת מפתח חדשה מבלי להסיר את הקודמת.

שגיאות טיפוסיות ואיך להימנע מהן

• שימוש ב-DES3-CBC-SHA1 או RC4—שני האלגוריתמים פגיעים. השבת דרך ngx_http_auth_spnego_module על KDC ו-0600.
• keytab אחד לכל השירותים על מארח—אם הוא נפרץ, הכל אבוד. כל שירות צריך keytab משלו עם הרשאות רק עבור אותו שירות.
• KDC נגיש מהרשת הציבורית. יציאות 88/tcp ו-749/tcp (kadmin) חייבות להיות חסומות מבחוץ.
• אין ניטור של פקיעת עקרונות וסיבוב מפתחות. עיקרון שפג תוקפו חוסם את השירות ללא הודעות שגיאה ברורות.

התהליך שלנו

1. ביקורת. קבע אילו שירותים צריכים כיסוי, האם קיים AD או LDAP פשוט, ומספר מכונות הלקוח.
2. עיצוב. פתח את מבנה ה-REALM, רשומות DNS SRV וטופולוגיית KDC (ראשי + N משניים). עבור התקנות גדולות, הקצה replica בכל מרכז נתונים.
3. יישום. פריס KDC, צור עקרונות שירות, הנפק keytabs, הגדר PAM (www-data) ו-NSS על הלקוחות. במקביל הגדר NTP עם התראות סחיפה.
4. בדיקות. ודא ktadd -norandkey, supported_enctypes, allow_weak_crypto = false ו-SSO בדפדפן דרך SPNEGO.

מה כלול בעבודה

• ביקורת של התשתית והשירותים הנוכחיים.
• עיצוב REALM ורשומות DNS SRV.
• פריסת KDC (ראשי + משני) עם שכפול אוטומטי.
• הגדרת keytab עבור HTTP, SSH, LDAP ויישומים מותאמים.
• שילוב עם PAM, NSS, SSSD ושרתי web.
• תיעוד ו-runbook עבור צוות התפעול.
• הדרכת מנהלים (שעתיים).
• תמיכת אחריות ל-30 יום לאחר המסירה.

צור קשר להערכת פרויקט—ננתח את התצורה שלך ביום אחד. קבל פתרון Kerberos מוכן שעובד ללא תקלות. שיפור אבטחת Kerberos דורש השבתת הצפנה חלשה ואכיפת אימות הדדי.