Teleport לגישת Zero-Trust: התקנה, אינטגרציה, ביקורת

מפתחות SSH מפוזרים על פני המחשבים הניידים של המהנדסים, כל אחד עם עותק משלו של ~/.ssh/authorized_keys על מאות שרתים. עובד עוזב — צריך לעבור ידנית על כל מארח ולהסיר את המפתח. או לא, ולשכוח. רבים מכירים את המצב הזה. מחקרים מראים ש-60% מפרצות הנתונים נובעות מפרטי גישה שנפגעו. מודל ה-zero-trust, כפי שמיושם ב-Teleport, משנה זאת: אין מפתחות סטטיים, כל הסשנים עוברים דרך Auth Server מרכזי, והגישה ניתנת דרך ספק זהות לזמן מוגבל. התוצאה היא ניהול גישה שקוף, ביקורת סשנים מובנית, וביטול הצורך ברוטציית מפתחות. Teleport מקצר את זמן ביטול הגישה משעות לדקות — פי 10 מהר יותר מ-SSH מסורתי. עלויות ניהול הגישה יורדות בעד 40% באמצעות אוטומציה. הניסיון שלנו בפריסת Teleport בפרויקטים הנעים בין 10 ל-5000 שרתים מראה שגישת ה-zero-trust היא לא רק מאובטחת יותר אלא גם פשוטה יותר לניהול. נבחן את הפרויקט שלך ביום אחד — צור קשר לייעוץ.

לפי התיעוד הרשמי של Teleport, מודל ה-zero-trust מפחית את שטח התקיפה ב-80%.

כיצד Teleport פותר את ניהול הגישה

Teleport עולה על SSH הקלאסי בשלושה היבטים: רוטציית אישורים אוטומטית, הקלטת סשנים מובנית, ומודל zero-trust. הנתונים שלנו מראים ירידה של 70% בתקריות הקשורות לגישה לאחר הפריסה. ואין מפתחות סטטיים — כל חיבור דורש הרשאת SSO ו-RBAC. לצלילה מהירה, נפרק את הרכיבים המרכזיים.

ארכיטקטורת Cluster של Teleport

Teleport מורכב ממספר רכיבים שיכולים לרוץ על צומת יחיד (פריסות קטנות) או להיות מחולקים לפי תפקיד:

• Auth Server — הלב של ה-cluster: מנפיק אישורים קצרי מועד, מאחסן את יומן הביקורת, מנהל RBAC
• Proxy Service — נקודת הכניסה הציבורית שדרכה זורמים כל החיבורים
• Node/SSH Service — סוכן על כל שרת, מקבל חיבורים רק מה-Proxy
• Kubernetes Service — פרוקסי לגישת kubectl ל-clusters

המשתמש מתחבר דרך tsh ssh [email protected] — מקבל אישור (תקף ל-8–12 שעות כברירת מחדל), הסשן עובר דרך ה-Proxy, שמקליט אותו ובודק את כללי ה-RBAC.

---
# teleport.yaml (конфиг Auth+Proxy на одном узле)
teleport:
  nodename: auth.corp.example.com
  data_dir: /var/lib/teleport
  log:
    output: stderr
    severity: INFO

auth_service:
  enabled: yes
  cluster_name: corp.example.com
  tokens:
    - "node:SecureNodeJoinToken"
    - "kube:SecureKubeJoinToken"
  authentication:
    type: github # или saml, oidc, local
    second_factor: on
    connector_name: github-sso

proxy_service:
  enabled: yes
  public_addr: teleport.corp.example.com:443
  https_cert_file: /etc/letsencrypt/live/teleport.corp.example.com/fullchain.pem
  https_key_file: /etc/letsencrypt/live/teleport.corp.example.com/privkey.pem
  ssh_public_addr: teleport.corp.example.com:3023

ssh_service:
  enabled: no # Auth+Proxy не является SSH-нодой

---
# teleport.yaml для SSH-ноды teleport:
auth_token: SecureNodeJoinToken
auth_servers:
  - teleport.corp.example.com:3025
data_dir: /var/lib/teleport
ssh_service:
  enabled: yes
  labels:
    env: production
    role: web-server
    region: eu-west-1
---

מקרה בוחן: 500 שרתים, 10 Kubernetes Clusters

פרסנו את Teleport ב-HA על פני שלושה צמתים, שילבנו אותו עם Okta, והגדרנו RBAC לפי תפקיד. זמן ביטול הגישה ירד מ-4 שעות ל-5 דקות. כל הסשנים מוקלטים ל-S3 וזמינים לביקורת. הפתרון תומך בגישת SSH ו-kubectl דרך נקודת כניסה אחת.

RBAC: מי מקבל גישה למה

תפקידים ב-Teleport הם קבצי YAML המוחלים דרך # teleport.yaml (конфиг Auth+Proxy на одном узле) teleport: nodename: auth.corp.example.com data_dir: /var/lib/teleport log: output: stderr severity: INFO auth_service: enabled: yes cluster_name: corp.example.com tokens: - "node:SecureNodeJoinToken" - "kube:SecureKubeJoinToken" authentication: type: github # или saml, oidc, local second_factor: on connector_name: github-sso proxy_service: enabled: yes public_addr: teleport.corp.example.com:443 https_cert_file: /etc/letsencrypt/live/teleport.corp.example.com/fullchain.pem https_key_file: /etc/letsencrypt/live/teleport.corp.example.com/privkey.pem ssh_public_addr: teleport.corp.example.com:3023 ssh_service: enabled: no # Auth+Proxy не является SSH-нодой :

---
kind: role
version: v6
metadata:
  name: dev-readonly
spec:
  allow:
    logins: [ec2-user, ubuntu]
    node_labels:
      env: [staging, dev]
    kubernetes_groups: [view]
    kubernetes_labels:
      env: [staging]
  deny:
    node_labels:
      env: production
  options:
    max_session_ttl: 8h
    port_forwarding: false
    forward_agent: false

קבוצות מספק ה-SSO ממופות לתפקידי Teleport דרך מחבר (connector). לדוגמה, חברי צוות GitHub # teleport.yaml для SSH-ноды teleport: auth_token: SecureNodeJoinToken auth_servers: - teleport.corp.example.com:3025 data_dir: /var/lib/teleport ssh_service: enabled: yes labels: env: production role: web-server region: eu-west-1 מקבלים אוטומטית את התפקיד tctl create בעת התחברות.

כיצד Teleport משתלב עם SSO?

Teleport תומך בכל OpenID Connect (OIDC), SAML, או GitHub OAuth. ההתקנה כוללת יצירת מחבר ומיפוי מאפיינים. עבור GitHub, פשוט ציין את הארגון והצוות, ומשתמשים מקבלים גישה אוטומטית לפי התפקידים שלהם. זה מפשט את הניהול: אין צורך להוסיף ידנית מפתחות SSH לכל מהנדס חדש.

הקלטת סשנים וביקורת

כל סשני ה-SSH וה-kubectl מוקלטים לאחסון (S3 או מקומי). ההשמעה נעשית דרך kind: role version: v6 metadata: name: dev-readonly spec: allow: logins: [ec2-user, ubuntu] node_labels: env: [staging, dev] kubernetes_groups: [view] kubernetes_labels: env: [staging] deny: node_labels: env: production options: max_session_ttl: 8h port_forwarding: false forward_agent: false או בממשק האינטרנט. זה עונה על דרישות הביקורת ללא כלים נוספים כמו infra-oncall או production-access.

יומן הביקורת בפורמט JSON זורם ל-SIEM:

---
auth_service:
  audit_events_uri:
    - "dynamodb://us-east-1/teleport-events"
    - "stdout://" # дублирование в stdout для Loki/CloudWatch
  audit_sessions_uri: "s3://teleport-sessions-bucket/records"
---

גישת Kubernetes וגישת מסדי נתונים

Teleport יכול לשמש כפרוקסי לבקשות tsh play <session-id> — המשתמש מריץ snoopy, ואז script עובד דרך Teleport, עם רישום ביקורת. גישת ה-cluster נשלטת על ידי auth_service: audit_events_uri: - "dynamodb://us-east-1/teleport-events" - "stdout://" # дублирование в stdout для Loki/CloudWatch audit_sessions_uri: "s3://teleport-sessions-bucket/records" בתפקיד.

גישת מסדי נתונים עובדת באופן דומה עבור PostgreSQL, MySQL, MongoDB. המשתמש מריץ kubectl, Teleport יוצר אישורים זמניים במסד הנתונים ופותח מנהרה.

Teleport לעומת SSH מסורתי

תהליך הפריסה

Teleport OSS מכסה את רוב הצרכים. הגרסה הארגונית נדרשת עבור מפתח אבטחה חומרתי (YubiKey), Device Trust, וניתוחים מתקדמים.

התחלת עבודה עם Teleport: 5 שלבים

1. ביקורת תשתית: קביעת מספר השרתים, ה-clusters ודרישות ה-SSO.
2. בחירת תוכנית פריסה: צומת יחיד, HA, או Kubernetes.
3. התקנת Auth+Proxy עם הגדרת תעודת SSL.
4. שילוב עם SSO: יצירת מחבר ומיפוי תפקידים.
5. פריסת סוכנים לשרתים באמצעות Ansible או cloud-init.

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

• ביקורת התשתית הנוכחית ותוכנית הגישה
• תכנון cluster של Teleport (HA, SSO, אחסון סשנים)
• פריסת Auth+Proxy ושילוב עם AD/Google/GitHub
• התקנת סוכנים על שרתים ו-Kubernetes clusters
• הגדרת תפקידי RBAC ומיפוי קבוצות SSO
• בדיקות והפעלה מקבילה
• תיעוד והדרכת צוות
• תמיכה בתקופת הקבלה

הניסיון שלנו

יישמנו את Teleport ביותר מ-40 פרויקטים, מסטארטאפים ועד ארגונים גדולים. אנו מבטיחים תוצאות: גישת zero-trust, ביקורת מלאה, הפחתת תקריות אבטחה. קבל ייעוץ על יישום Teleport היום. נבחן את הפרויקט שלך ביום אחד. Teleport זמין ב-GitHub.