راه‌اندازی HashiCorp Vault روی سرور مجازی و اختصاصی: مدیریت امن رمزها و کلیدهای API

نگهداری رمز پایگاه داده، کلید API و گواهی TLS در فایل‌های متنی، متغیرهای محیطی بدون کنترل یا مخزن کد، ریسک جدی برای هر تیم فنی است. یک لاگ اشتباه، دسترسی ناخواسته به سرور یا انتشار یک مخزن خصوصی می‌تواند این اطلاعات را فاش کند. HashiCorp Vault برای حل همین مسئله ساخته شده است: اسرار را در یک مخزن رمزنگاری‌شده نگه می‌دارد، دسترسی به آن‌ها را با سیاست مشخص کنترل می‌کند و امکان ثبت رویدادهای دسترسی و چرخش کلیدها را فراهم می‌سازد. در این آموزش، راه‌اندازی HashiCorp Vault روی سرور مجازی یا اختصاصی لینوکس را مرحله‌به‌مرحله انجام می‌دهیم. نمونه‌ها بر پایه Ubuntu 22.04 و Vault با storage backend نوع Raft نوشته شده‌اند، اما مفاهیم در توزیع‌های دیگر نیز یکسان است. پیش از اجرای دستورات، نام دامنه‌ای مانند vault.example.com را به IP سرور اشاره دهید و مطمئن شوید پورت‌های لازم در فایروال باز هستند.

پیش‌نیازهای نصب Vault روی سرور

برای محیط آزمایشی، یک سرور مجازی با یک هسته پردازنده، ۲ گیگابایت RAM و حداقل ۲۰ گیگابایت دیسک کافی است. محیط عملیاتی به منابع بیشتری نیاز دارد و اندازه آن به تعداد درخواست‌ها، حجم audit log و تعداد نودها بستگی دارد. دیسک باید پایدار و ترجیحاً SSD باشد؛ از دست رفتن داده Raft به معنی از دست رفتن دسترسی به اسرار است. پیش‌نیازهای اصلی عبارت‌اند از: - Ubuntu یا Debian به‌روز با دسترسی sudo - دامنه و گواهی TLS معتبر - ساعت سیستم همگام با NTP - فایروال با دسترسی کنترل‌شده به پورت ۸۲۰۰ - برنامه پشتیبان‌گیری برای فایل‌های داده Vault - دسترسی جداگانه برای مدیر سیستم و مصرف‌کنندگان اسرار، با یک دسترسی SSH امن‌سازی‌شده برای مدیران سیستم بهتر است Vault را روی همان سروری که برنامه اصلی اجرا می‌شود نصب نکنید، مگر در محیط توسعه. جداسازی سرور، سطح حمله را کمتر می‌کند و امکان اعمال سیاست شبکه مستقل را می‌دهد. برای بار کاری حساس، سرور اختصاصی یا حداقل یک VPS با دیسک و شبکه اختصاصی انتخاب مناسب‌تری است.

نصب HashiCorp Vault

ابتدا بسته‌های سیستم را به‌روز و ابزارهای مورد نیاز را نصب کنید:

sudo apt update
sudo apt install -y gpg wget lsb-release ca-certificates

کلید امضای مخزن HashiCorp را اضافه کنید و مخزن رسمی را فعال کنید:

wget -O- https://apt.releases.hashicorp.com/gpg \

  | gpg --dearmor \
  | sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg >/dev/null

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
https://apt.releases.hashicorp.com $(lsb_release -cs) main" \

  | sudo tee /etc/apt/sources.list.d/hashicorp.list

sudo apt update
sudo apt install -y vault

نسخه نصب‌شده را بررسی کنید:

vault version

برای اجرای سرویس، یک کاربر سیستمی و مسیر داده بسازید:

sudo useradd --system --home /etc/vault.d --shell /usr/sbin/nologin vault
sudo mkdir -p /opt/vault/data /etc/vault.d
sudo chown -R vault:vault /opt/vault /etc/vault.d
sudo chmod 750 /opt/vault/data

در محیط عملیاتی، دسترسی مسیر داده را فقط به کاربر Vault و مدیران مورد اعتماد بدهید. قرار دادن این مسیر روی دیسک رمزنگاری‌شده یا پارتیشن جداگانه، ریسک دسترسی مستقیم به فایل‌ها را کاهش می‌دهد؛ هرچند رمزنگاری داده در خود Vault همچنان لایه اصلی حفاظت است.

پیکربندی Storage و Listener

فایل /etc/vault.d/vault.hcl را ایجاد کنید:

ui = true
api_addr     = "https://vault.example.com:8200"
cluster_addr = "https://vault.example.com:8201"
listener "tcp" {
  address         = "0.0.0.0:8200"
  cluster_address = "0.0.0.0:8201"
  tls_cert_file = "/etc/vault.d/tls/fullchain.pem"
  tls_key_file  = "/etc/vault.d/tls/privkey.pem"
  tls_min_version = "tls13"
}
storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-1"
}
disable_mlock = true

در این نمونه، Raft داده‌ها را مستقیماً روی دیسک نگه می‌دارد و برای یک نود ساده به سرویس جداگانه‌ای مانند Consul نیاز نیست. در کلاستر چندنودی، برای هر نود node_id یکتا تعیین کنید و ارتباط پورت ۸۲۰۱ را فقط میان نودهای Vault مجاز کنید. برای نصب و پیکربندی یکسان این تنظیمات روی چند نود، اتوماسیون پیکربندی چند سرور با Ansible می‌تواند از تکرار دستی جلوگیری کند. گزینه disable_mlock راه‌اندازی را در بسیاری از محیط‌های ابری آسان می‌کند، اما به این معناست که سیستم‌عامل می‌تواند صفحات حافظه Vault را swap کند. اگر امکان فعال‌سازی mlock و غیرفعال کردن swap را دارید، برای محیط حساس از آن استفاده کنید. در هر حالت، swap را بررسی کنید:

swapon --show
sudo swapoff -a

فعال‌سازی HTTPS

Vault باید از اولین درخواست با HTTPS در دسترس باشد. گواهی را با Let’s Encrypt، گواهی سازمانی یا یک مرجع داخلی معتبر تهیه کنید. فایل‌ها را در مسیر محدود قرار دهید:

sudo mkdir -p /etc/vault.d/tls
sudo cp fullchain.pem /etc/vault.d/tls/
sudo cp privkey.pem /etc/vault.d/tls/
sudo chown -R vault:vault /etc/vault.d/tls
sudo chmod 600 /etc/vault.d/tls/privkey.pem
sudo chmod 644 /etc/vault.d/tls/fullchain.pem

اگر از reverse proxy مانند Nginx استفاده می‌کنید، TLS را در همان لایه خاتمه دهید و ارتباط Nginx تا Vault را نیز HTTPS نگه دارید. ارسال توکن‌های Vault روی HTTP داخلی، در شبکه‌ای که چند سرویس یا کاربر دارد، انتخاب امنی نیست. فایروال را محدود کنید. پورت ۸۲۰۰ باید فقط از شبکه مدیریت و سرویس‌های مصرف‌کننده قابل دسترسی باشد و پورت ۸۲۰۱ فقط میان نودهای Vault باز بماند. نمونه زیر با ufw است؛ برای قوانین دقیق‌تر یا مهاجرت از iptables می‌توانید راه‌اندازی فایروال nftables را هم ببینید:

sudo ufw allow from 203.0.113.10 to any port 8200 proto tcp
sudo ufw allow from 10.10.0.0/16 to any port 8200 proto tcp
sudo ufw allow from 10.10.0.0/16 to any port 8201 proto tcp
sudo ufw enable

اجرای سرویس و Initialize کردن Vault

سرویس را فعال کنید:

sudo systemctl enable vault
sudo systemctl start vault
sudo systemctl status vault

متغیر آدرس را برای کلاینت تنظیم کنید:

export VAULT_ADDR="https://vault.example.com:8200"

برای بررسی سلامت سرویس:

vault status

در اولین اجرا، Vault در وضعیت initialized نیست. دستور زیر ساختار رمزنگاری را ایجاد می‌کند:

vault operator init -key-shares=5 -key-threshold=3

خروجی شامل پنج کلید Unseal و یک توکن اولیه root است. این اطلاعات را در ترمینال، چت یا فایل عادی ذخیره نکنید. هر کلید Unseal را نزد فرد یا سامانه‌ای جداگانه نگه دارید و توکن root را پس از ایجاد حساب مدیریتی محدود کنار بگذارید. اگر حداقل سه کلید در دسترس نباشد، Vault قابل Unseal شدن نخواهد بود. برای باز کردن قفل:

vault operator unseal

این دستور را سه بار با سه کلید متفاوت اجرا کنید. پس از آن، با توکن اولیه وارد شوید:

vault login

در طراحی‌های حساس‌تر، استفاده از Auto Unseal با KMS ابری یا HSM باعث می‌شود کلیدهای Unseal به‌صورت دستی روی هر نود وارد نشوند. این روش وابستگی عملیاتی و هزینه بیشتری دارد، اما برای کلاسترهای چندنودی و بازیابی خودکار مناسب‌تر است.

ذخیره رمزها و کلیدهای API با KV Secrets Engine

موتور KV نسخه ۲ را فعال کنید:

vault secrets enable -path=secret kv-v2

یک مقدار آزمایشی برای برنامه فروشگاه بنویسید:

vault kv put secret/shop \
  db_username="shop_app" \
  db_password="رمز-طولانی-و-تصادفی" \
  payment_api_key="کلید-درگاه"

برای خواندن آن:

vault kv get secret/shop

KV v2 نسخه‌های قبلی مقدار را نگه می‌دارد و امکان بازگردانی یا حذف نرم را فراهم می‌کند. تعداد نسخه‌ها را متناسب با نیاز تنظیم کنید:

vault secrets tune -max-versions=10 secret/

اسرار را بر اساس برنامه و محیط جدا کنید؛ برای مثال secret/shop/production و secret/shop/staging. رمزها را در خروجی CI، لاگ برنامه یا پیام خطا چاپ نکنید. دسترسی سرویس باید از مسیر API یا Agent انجام شود، نه با قرار دادن توکن دائمی در کد.

تعریف Policy با کمترین سطح دسترسی

یک Policy فقط اجازه خواندن مسیر مورد نیاز را می‌دهد. فایل shop-read.hcl را بسازید:

path "secret/data/shop" {
  capabilities = ["read"]
}
path "secret/metadata/shop" {
  capabilities = ["read", "list"]
}

Policy را بارگذاری کنید:

vault policy write shop-read shop-read.hcl

از اعطای قابلیت‌های sudo، create یا delete به برنامه‌ای که فقط باید رمز را بخواند خودداری کنید. Policy را برای هر سرویس و محیط جداگانه نگه دارید و تغییرات آن را در مخزن کنترل نسخه، بدون درج هیچ مقدار محرمانه‌ای، بازبینی کنید. برای محیط‌های بدون سیستم هویت مرکزی می‌توانید یک توکن محدود بسازید:

vault token create \
  -policy=shop-read \
  -ttl=24h \
  -renewable=true

در محیط عملیاتی، روش‌هایی مانند AppRole، Kubernetes Auth، LDAP یا OIDC معمولاً از توکن ثابت بهتر هستند. AppRole برای ماشین‌ها شناسه نقش و secret جداگانه دارد و می‌توان هر دو را با چرخه عمر کوتاه و دسترسی محدود مدیریت کرد.

مقایسه استقرار روی VPS و سرور اختصاصی

انتخاب زیرساخت به تعداد درخواست‌ها، سطح دسترس‌پذیری و الزامات امنیتی بستگی دارد.

ویژگی	سرور مجازی	سرور اختصاصی
هزینه شروع	کمتر و قابل پیش‌بینی	بیشتر، همراه با هزینه سخت‌افزار
جداسازی منابع	وابسته به میزبان و سیاست ارائه‌دهنده	کامل‌تر و قابل کنترل‌تر
مقیاس‌پذیری	افزایش منابع معمولاً سریع	نیازمند ارتقای سخت‌افزار یا مهاجرت
مناسب برای	تیم‌های کوچک، staging و کلاستر کم‌ترافیک	اسرار حیاتی، بار ثابت و الزامات سخت‌گیرانه
نگهداری	ساده‌تر با snapshot و پنل	کنترل کامل‌تر روی دیسک و شبکه

برای بیشتر تیم‌ها، یک VPS با دیسک SSD، شبکه خصوصی و پشتیبان‌گیری منظم شروع مناسبی است. اگر جداسازی فیزیکی، I/O ثابت یا کنترل کامل روی HSM و شبکه لازم است، سرور اختصاصی ارزش هزینه اضافی را دارد.

پشتیبان‌گیری، مانیتورینگ و عملیات روزانه

از snapshotهای Raft به‌صورت زمان‌بندی‌شده نسخه پشتیبان بگیرید:

export VAULT_TOKEN="توکن-مدیریتی-محدود"
vault operator raft snapshot save /var/backups/vault-$(date +%F).snap

فایل snapshot را به مقصدی جدا از سرور اصلی و ترجیحاً رمزنگاری‌شده منتقل کنید. بازیابی را در یک محیط آزمایشی به‌طور دوره‌ای امتحان کنید؛ داشتن فایل backup بدون آزمون restore، تضمین بازیابی نیست. Audit log را فعال کنید:

vault audit enable file file_path=/var/log/vault_audit.log

دسترسی فایل لاگ را محدود و چرخش آن را با logrotate تنظیم کنید. Audit log ممکن است مسیرها و شناسه‌های حساس داشته باشد، بنابراین آن را مانند داده محرمانه نگه دارید. وضعیت سرویس، فضای دیسک، زمان پاسخ API، تعداد خطاهای احراز هویت و وضعیت Seal را مانیتور کنید. هشدار برای restart غیرمنتظره، پر شدن دیسک، افزایش خطاهای ۵xx و تغییر Policy به تشخیص سریع حادثه کمک می‌کند. راه‌اندازی مانیتورینگ سرور با Prometheus و Grafana نقطه شروع مناسبی برای این بخش است، و برای جمع‌آوری متمرکز audit log از چند نود Vault می‌توانید از راه‌اندازی لاگ متمرکز با Grafana Loki و Alloy استفاده کنید.

خطاهای رایج در راه‌اندازی Vault

فراموش کردن HTTPS: اگر VAULT_ADDR با HTTP تنظیم شود یا گواهی نامعتبر باشد، توکن‌ها ممکن است در معرض شنود قرار بگیرند. نگهداری همه کلیدهای Unseal در یک مکان: این کار هم ریسک سرقت را بالا می‌برد و هم هدف تقسیم کلیدها را از بین می‌برد. استفاده دائمی از root token: root را فقط برای bootstrap و عملیات اضطراری نگه دارید و برای کارهای روزمره Policy محدود بسازید. باز گذاشتن پورت‌ها برای اینترنت: پورت‌های Vault را در فایروال و شبکه خصوصی محدود کنید؛ وجود رمز عبور قوی جایگزین کنترل شبکه نیست. نبود تست بازیابی: قبل از استفاده عملیاتی، سناریوی خرابی دیسک، از دست رفتن نود و بازیابی snapshot را تمرین کنید.

جمع‌بندی

راه‌اندازی HashiCorp Vault روی سرور با نصب بسته پایان نمی‌یابد. باید HTTPS، storage پایدار، فرآیند Unseal، Policy حداقلی، احراز هویت مناسب، audit log و پشتیبان‌گیری را کنار هم طراحی کنید. ابتدا معماری ساده یک‌نودی را در محیط آزمایشی بررسی کنید، سپس با توجه به نیاز دسترس‌پذیری به کلاستر Raft و Auto Unseal مهاجرت کنید. اگر برای اجرای Vault به سروری با دیسک پرسرعت، شبکه پایدار و امکان جداسازی محیط‌های staging و production نیاز دارید، می‌توانید مشخصات سرورهای ابری آریانت را بررسی کنید. (پیش از خرید، منابع مورد نیاز، محل نگهداری backup و محدودیت‌های شبکه را با بار واقعی خود مقایسه کنید.)