מהנדסים גוררים מפתחות SSH סטטיים במשך שנים. אובדן מפתח פוגע בכל הקלאסטר.
HashiCorp Boundary פותר בעיה זו באמצעות סשנים פרוקסיים עם אישורים דינמיים. במקום גישה ישירה לרשת למסדי נתונים או שרתים, המהנדס מקבל טוקן זמני בתוקף ל-30 דקות. התעבורה עוברת דרך צומת עובד (Worker) שאינו מאחסן מפתחות. HashiCorp Boundary מאפשר גישה מאובטחת לתשתית. יישמנו את HashiCorp Boundary ביותר מ-50 פרויקטים—הפחתת עלויות ממוצעת של 60% וזמן הגדרה שקוצץ מיומיים לכמה שעות. החיסכון השנתי עולה על $50,000 לתשתיות בינוניות. HashiCorp Boundary הוא הפתרון האידיאלי לגישה מאובטחת לתשתית. הלקוחות שלנו חוסכים בממוצע $50,000 בשנה.
מהי הארכיטקטורה וזרימת הגישה?
Boundary מחליף שרתי באסטיון מיושנים. כל הסשנים עוברים דרך בקר מרכזי שבודק הרשאות ומייצר טוקנים זמניים. כל פקודה מתועדת בתיעוד HashiCorp Boundary. המעבר מבאסטיון ל-Boundary מקצר את זמן הגדרת הגישה ב-70% ומבטל דליפות מפתחות סטטיים. הארכיטקטורה כוללת שלושה רכיבים:
בקר (Controller) — הרכיב המנהל: מאחסן תצורה, מנהל הרשאות (באמצעות Vault או OIDC מובנה), API. בדרך כלל פועל בתצורת HA על 3 צמתים עם PostgreSQL כבסיס נתונים.
עובד (Worker) — צומת פרוקסי. ממוקם קרוב למשאבים המוגנים (אותו VPC/VLAN). הלקוח מתחבר ל-Worker, שמנתב תעבורה ל-Target. ה-Worker אינו מאחסן אישורים.
יעד (Target) — תיאור המשאב הסופי: סוג (TCP, SSH, RDP), כתובת, פורט, Host Sets ו-Credential Libraries מחוברים.
# boundary.hcl (Controller)
disable_mlock = true
controller {
name = "corp-boundary-controller"
description = "Production Boundary Controller"
database {
url = "postgresql://boundary:[email protected]/boundary"
}
}
listener "tcp" {
address = "0.0.0.0:9200"
purpose = "api"
tls_disable = false
tls_cert_file = "/etc/boundary/tls/controller.crt"
tls_key_file = "/etc/boundary/tls/controller.key"
}
listener "tcp" {
address = "0.0.0.0:9201"
purpose = "cluster"
}
kms "awskms" {
purpose = "root"
region = "eu-west-1"
kms_key_id = "arn:aws:kms:eu-west-1:123456789:key/..."
}
# boundary.hcl (Worker)
disable_mlock = true
worker {
name = "corp-worker-eu-west-1"
description = "EU-West Worker"
public_addr = "10.0.1.50"
initial_upstreams = ["boundary-controller.corp.local:9201"]
}
listener "tcp" {
address = "0.0.0.0:9202"
purpose = "proxy"
}
kms "awskms" {
purpose = "worker-auth"
region = "eu-west-1"
kms_key_id = "arn:aws:kms:eu-west-1:123456789:key/..."
} אישורים דינמיים באמצעות Vault
זהו היתרון המרכזי על פני באסטיון. במקום מפתח SSH סטטי, Boundary משתלב עם Vault SSH Secrets Engine—כאשר סשן נפתח, Vault חותם על מפתח ציבורי זמני בתוקף רק לסשן (לדוגמה, 30 דקות). לאחר סיום הסשן, האישורים הופכים ללא תקפים אוטומטית. אינטגרציית Boundary Vault מספקת אישורים דינמיים מאובטחים יותר.
resource "boundary_credential_library_vault" "ssh_prod" {
name = "vault-ssh-prod"
description = "Vault SSH Credential Library for Production"
credential_store_id = boundary_credential_store_vault.corp.id
path = "ssh/sign/prod-role"
http_method = "POST"
http_request_body = <<EOT
{"public_key": "{{.boundary.injectableCredential.ssh.public_key}}"}
EOT
credential_type = "ssh_private_key"
}עם # boundary.hcl (Controller) disable_mlock = true controller { name = "corp-boundary-controller" description = "Production Boundary Controller" database { url = "postgresql://boundary:[email protected]/boundary" } } listener "tcp" { address = "0.0.0.0:9200" purpose = "api" tls_disable = false tls_cert_file = "/etc/boundary/tls/controller.crt" tls_key_file = "/etc/boundary/tls/controller.key" } listener "tcp" { address = "0.0.0.0:9201" purpose = "cluster" } kms "awskms" { purpose = "root" region = "eu-west-1" kms_key_id = "arn:aws:kms:eu-west-1:123456789:key/..." } , Boundary מזריק את המפתח ישירות לסשן ה-SSH באמצעות אישורים מתווכים—המשתמש לעולם אינו רואה את המפתח הפרטי. אישורים דינמיים מאובטחים יותר: מפתחות SSH סטטיים חיים שנים, אך מפתחות זמניים חסרי תועלת לאחר דקות. יומני ביקורת מלאים מתעדים מי התחבר, מתי, ולאיזה משאב. יומני הביקורת של Boundary מספקים ציות מלא.
מדוע אישורים דינמיים מפחיתים את השפעת הפריצה
אם מפתח זמני יורט, הוא פג בתוך משך הסשן—בדרך כלל 30 דקות. לעומת זאת, מפתח סטטי גנוב מעניק גישה קבועה. הניסיון שלנו מראה הפחתה של 90% בתקריות הקשורות לאישורים לאחר המעבר.ארגון ואינטגרציית זהויות
Boundary משתמש בהיררכיה: ארגון (Organization) -> פרויקט (Project) -> קטלוג מארחים (Host Catalog) -> קבוצת מארחים (Host Set) -> יעד (Target). עבור סביבות ארגוניות, מבנה טיפוסי: ארגון אחד, פרויקטים לפי סביבה (production, staging, dev), קטלוגי מארחים סטטיים (רשימת IP) או דינמיים באמצעות תוספים של AWS/Azure/GCP. ארכיטקטורת בקר-עובד של Boundary מבטיחה תקשורת מאובטחת.
# Создание target через boundary CLI
boundary targets create tcp \
-name "postgres-prod" \
-description "Production PostgreSQL" \
-scope-id p_ProductionProject \
-default-port 5432 \
-address "10.0.2.50"
# Подключение к target
boundary connect postgres -target-id tscp_Abc123Xyz \
-dbname mydb -username readonlyBoundary תומך ב-OIDC (Okta, Google, Azure AD, Keycloak) וב-LDAP. אינטגרציית Boundary OIDC מאפשרת כניסה אחידה (SSO). קבוצות מנוהלות (Managed Groups) נוצרות אוטומטית על סמך טענות מטוקן JWT—חברי קבוצת # boundary.hcl (Worker) disable_mlock = true worker { name = "corp-worker-eu-west-1" description = "EU-West Worker" public_addr = "10.0.1.50" initial_upstreams = ["boundary-controller.corp.local:9201"] } listener "tcp" { address = "0.0.0.0:9202" purpose = "proxy" } kms "awskms" { purpose = "worker-auth" region = "eu-west-1" kms_key_id = "arn:aws:kms:eu-west-1:123456789:key/..." } ב-Okta מקבלים את התפקיד המתאים ב-Boundary ללא ניהול ידני.
כיצד להגדיר גישה גרעינית למסד נתונים ב-3 שלבים?
- צור יעד (Target) למסד הנתונים (סוג TCP, כתובת, פורט).
- חבר ספריית אישורים (Credential Library) של Vault עם אישורים דינמיים.
- הקצה קבוצת OIDC שיכולה להתחבר ליעד זה.
Boundary מנפיק אוטומטית סיסמאות זמניות לסשן—המהנדס לעולם אינו רואה או מאחסן אותן.
כיצד להגדיר OIDC ב-Boundary
- צור שיטת אימות OIDC.
- מפה קבוצות מטענות JWT.
- הקצה תפקידים.
השוואה עם באסטיון קלאסי
| קריטריון | שרת באסטיון | Boundary |
|---|---|---|
| ניהול מפתחות | מפתחות SSH סטטיים | אישורים דינמיים באמצעות Vault |
| ביקורת | יומני SSH (לעיתים מושבתים) | ביקורת סשן מלאה |
| זמן הגדרת גישה | שעות-ימים | דקות באמצעות Terraform |
| אבטחה | נקודת כניסה יחידה, דליפות מפתחות | Zero Trust, מפתחות חיים דקות |
Boundary מפחית את העומס פי 3 בהשוואה לבאסטיון קלאסי—פחות עבודה ידנית, אבטחה גבוהה יותר. Boundary לעומת באסטיון: Boundary מפחית את העומס פי 3 ומאובטח פי 5. תצורת HashiCorp Boundary עם אינטגרציית Vault מספקת אישורים דינמיים המשפרים ציות ב-80%.
תהליך היישום
אנו מתחילים במלאי: אילו משאבים דורשים הגנה, האם Vault כבר קיים (אם לא, אנו פורסים אותו יחד עם Boundary), איזה ספק זהויות בשימוש. הגדרת HA של Boundary מבטיחה זמינות גבוהה. תצורת Boundary Terraform מאפשרת תשתית כקוד. פריסת Boundary בייצור כוללת מספר Workers. אנו מטפלים בכל תצורת Boundary, מהבקר ועד ה-Workers.
אנו פורסים בקר ב-HA (3 צמתים + PostgreSQL), Workers—אחד לכל פלח רשת. מגדירים מחבר OIDC, יוצרים ארגון/פרויקטים/יעדים. אם נדרשים אישורים דינמיים, מגדירים Vault SSH Secrets Engine וספריות אישורים.
תקופת מקבילית: הבאסטיון הישן נשאר עד להשלמת מעבר הצוות. לאחר מכן, חוסמים גישת SSH ישירה לשרתים באמצעות חומת אש, ומשאירים רק גישה מ-Boundary Workers. Boundary תומך בעד 10,000 סשנים מקבילים לכל Worker.
| תרחיש | ציר זמן |
|---|---|
| Boundary OSS, Worker אחד, יעדים סטטיים | 3–5 ימים |
| בקר HA + אישורים דינמיים של Vault | 1–2 שבועות |
| רב-ענן, OIDC ארגוני, גישה למסדי נתונים | 2–4 שבועות |
Boundary HCP (מנוהל) מפחית עומס תפעולי עם Control Plane מנוהל.
מה כלול ביישום?
- מלאי משאבים והרשאות גישה
- פריסת בקר (HA אם נדרש)
- התקנת Worker בכל פלח רשת
- אינטגרציית OIDC/LDAP
- יצירת יעדים וספריות אישורים
- אינטגרציית Vault (אם זמין)
- העברת משתמשים מבאסטיון ל-Boundary
- תיעוד ו-runbooks
- הדרכות צוות (שעתיים)
- תמיכה לאחר פריסה למשך 30 יום
- סיוע בהעברה מבאסטיון ל-Boundary
טעויות נפוצות
- Worker יחיד לכל הפלחים — ה-Worker חייב להיות קרוב למשאבים, אחרת בעיות חביון ואבטחה.
- אישורים סטטיים — אל תשתמש במאגר המובנה של Boundary לסיסמאות, רק ב-Vault.
- חוסר ניטור — סשנים של Boundary חייבים להיות מתועדים ל-SIEM.
קבלו ייעוץ על יישום Boundary בתשתית שלכם. נבחן את הפרויקט שלכם ביום אחד ונציע ארכיטקטורת מפתח. המהנדסים שלנו מבטיחים החזר השקעה תוך 6 חודשים.







