نقاط پایانی خصوصی و اینترانت

1) چرا یک شبکه خصوصی

• جداسازی PaaS/DB/storages از IP عمومی ؛
• انطباق آسان تر (PCI DSS/GDPR)
• تاخیرهای قابل پیش بینی و مسیریابی

2) مدل پایه: VPC/VNet و هاب ها

فضای آدرس: یک طرح CIDR تنها، بدون تقاطع (به عنوان مثال، '10. 0. 0. 0/12 'به محیط ها و هاب ها بریده می شود).
تقسیم بندی: زیر شبکه «ورود»، «برنامه»، «داده ها»، «عملیات»، «مشترک» با مسیرهای فردی/ACL/SG.
مرکز حمل و نقل: VPC/VNet مرکزی با دروازه (VPN/DirectConnect/ExpressRoute/Interconnect)، بین VPC peering/Transit Gateway و فایروال های شبکه.
دو پشته: برنامه ریزی IPv6 در پیشبرد (موجب صرفه جویی در NAT، بهبود مقیاس آدرس).

3) نقاط پایانی خصوصی: اصول

• ترافیک وارد شبکه ارائه دهنده می شود (نه از طریق اینترنت).
• خط مشی Endpoint جایی که می توانید بروید (پیشوند/ARN/منابع).
• DNS به IP خصوصی تعریف شده است (نگاه کنید به § 6).

اهداف معمول: فروشگاه های شیء (S3/GCS/Blob)، راز/KMS، صف ها، اتوبوس های رویداد، پایگاه داده های مدیریت شده، خدمات تحلیلی، ثبت کننده های مصنوعی.

4) ورود و تعادل در داخل

متعادل کننده بار داخلی (ILB) برای L4/7، ما فقط از زیر شبکه های خصوصی می بینیم.

• 'Service' از نوع 'LoadBalancer' با حاشیه نویسی داخلی.
• ورود از طریق ورودی داخلی (Nginx/Contour/Gateway API) در یک آدرس خصوصی.
• API دروازه (خصوصی): ادغام خصوصی با backends ؛ خارج - فقط از طریق لبه، در صورت لزوم.

مثال: K8s ورود به عنوان داخلی

yaml apiVersion: networking. k8s. io/v1 kind: Ingress metadata:
name: api-internal annotations:
kubernetes. io/ingress. class: "nginx"
alb. ingress. kubernetes. io/scheme: internal # or provider equivalent spec:
rules:
- host: api. internal. corp http:
paths:
- path: /v1/
pathType: Prefix backend:
service:
name: api port: { number: 8080 }

5) کانتور خروج: «پیش فرض - انکار»

• دروازه NAT (برای به روز رسانی/مخازن) + خروج allowlist از طریق FQDN/IP ؛
• بازرسی TLS/پروکسی اگر سیاست نیاز به کنترل ؛
• نقاط پایانی خصوصی به PaaS/ثبات به جای NAT.
• SG/NACL: مجوز صریح در هر سرویس، «شرق و غرب» - حداقل.
• سیاست های خروج K8s (CNI/OPA Gatekeeper/Calico NetworkPolicy) - ممنوعیت IP خارجی، مجوز خوشه/نقطه پایانی.

6) DNS: تقسیم افق и مناطق خصوصی

مناطق داخلی جداگانه ("داخلی. (و عمومی).
مناطق DNS خصوصی برای خدمات ارائه دهنده: نام های عمومی را نادیده بگیرید (به عنوان مثال، "سطل. اس 3. منطقه. آمازوناوس. com ') به سوابق خصوصی A/AAAA.
حمل و نقل/DNS مشروط между ابر ↔ پیش فرض.
فرمت نام: encapsulate محیط/منطقه ('api. اتحادیه اروپا 1. داخلی است. corp ')، اجتناب از PII.

api. internal. corp. A  10. 20. 30. 40 s3. bucket. corp. A  10. 100. 0. 25 # via private endpoint

7) الگوهای اتصال

Peering (VPC↔VPC/VNet↔VNet): ساده و سریع ؛ transit همیشه پشتیبانی نمیشود → از Transit Gateway/Virtual WAN/Cloud Router برای hub-and-spoke استفاده کنید.
ابر ⇄ On-prem: VPN IPsec برای شروع، سپس خط اجاره (DC/ER/IC) با BGP و پشتیبان گیری (دو ارائه دهنده، نقاط ورودی مختلف).
VRF/تقسیم بندی دامنه مسیر: جداسازی prod/stage/dev و محیط کارت.

8) اعتماد صفر و احراز هویت داخلی

mTLS-پیش فرض (مش سرویس: Istio/Linkerd/Consul)، هویت دستگاه: SPIFFE/SPIRE.
سیاست های L7: مجوز توسط JWT/claims/scopes، محدودیت مسیرها/روش ها در سطح پروکسی.

اسرار: HashiCorp Vault/КMS + اپراتور اسرار خارجی ؛ اعتبارنامه کوتاه مدت (STS)

Bastion/Privileged Access: دسترسی به privatka تنها از طریق جلسه کارگزار/JIT (MFA، ضبط فرمان).

مثال: نماینده فیلتر mTLS + JWT-authz (قطعه)

yaml transport_socket:
name: tls typed_config: {... spiffe://svc. api... }
http_filters:
- name: envoy. filters. http. jwt_authn typed_config:
providers:
oidc: { issuer: https://idp. corp, audiences: ["api"], remote_jwks: {...} }
rules: [{ match: { prefix: "/v1" }, requires: { provider_name: oidc } }]

9) داده ها و PaaS در داخل خصوصی

پایگاه داده ها/خوشه ها: فقط آدرس های خصوصی ؛ پنل مدیریت از طریق سنگر/JIT.
مخازن: دسترسی از VPC از طریق نقطه پایانی خصوصی ؛ سیاست endpoint اجازه می دهد تا فقط سطل/ظروف مورد نظر.
صف/اتوبوس: رابط های خصوصی ؛ تولید کنندگان/مصرف کنندگان - در همان VPC/peering.
ثبّاتهای مصنوع: دسترسی خصوصی از گردانندههای CI/CD در زیرشبکههای خصوصی.

10) قابلیت مشاهده در شبکه های خصوصی

OpenTelemetry Collector - به عنوان یک دروازه تله متری: صادر کنندگان داخلی به خود میزبانی (Prometheus/Tempo/Loki/ClickHouse) و یا به مدیریت از طریق نقاط پایانی خصوصی.
سیاهههای مربوط به جریان/NSG/NACL سیاهههای مربوط و تجزیه و تحلیل قابلیت دسترسی مورد نیاز است.
SLO-برش: «سایت/منطقه/vpc/subnet»، هشدار برای خروج و غیر منتظره «جهت اینترنت».

11) تست و تأیید

خط مشی به عنوان کد (OPA/Gatekeeper) برای قوانین شبکه/ورود/خدمات.
مسیرهای قناری: دامنه های تست در DNS خصوصی، بررسی های مصنوعی از زیر شبکه های مختلف/AZ/مناطق.
شبکه هرج و مرج: تاخیر/تلفات در بین VPC/inter-AZ (netem/Toxiproxy)، چک کردن زمان و سیاست های مجدد.

12) نمونه های پیکربندی

12. 1 Terraform: برچسب ها و مسیرها (ایده)

hcl resource "aws_route_table" "app" {
vpc_id = aws_vpc. core. id tags = { Name = "rt-app", env = var. env, zone = "private" }
}
Route on PrivateLink endpoint (interface endpoint is created separately)
resource "aws_vpc_endpoint_route_table_association" "s3" {
route_table_id = aws_route_table. app. id vpc_endpoint_id = aws_vpc_endpoint. s3. id
}

12. 2 K8s NetworkPolicy: انکار همه چیز به جز آنچه شما نیاز دارید

yaml apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata: { name: deny-all }
spec:
podSelector: {}
policyTypes: ["Ingress","Egress"]
kind: NetworkPolicy metadata: { name: allow-core }
spec:
podSelector: { matchLabels: { app: api } }
egress:
- to:
- namespaceSelector: { matchLabels: { ns: db } }
ports: [{ port: 5432, protocol: TCP }]
- to:
- ipBlock: { cidr: 10. 100. 0. 0/16 }  # private endpoints ports: [{ port: 443, protocol: TCP }]

12. 3 ورود Nginx (طرح داخلی) + HSTS

yaml metadata:
annotations:
alb. ingress. kubernetes. io/scheme: internal nginx. ingress. kubernetes. io/hsts: "true"

13) ضد گلوله

مشترک «مدیریت-اینترنت» از زیرشبکههای خصوصی ؛ عدم کنترل خروج

DNS تقسیم مغز و کتابچه راهنمای تصادفی «/etc/hosts ».
CIDR های متقاطع و «عروسک های لانه سازی NAT».
نقاط پایانی عمومی برای پایگاه های داده/ذخیره سازی «به خاطر راحتی».
بدون ممیزی جریان/قانون ؛ «باز کردن» SG '0. 0. 0. 0/0`.
کلیدهای دسترسی استاتیک طولانی مدت در کد/CI.

14) هزینه و عملکرد

نقطه پایان خصوصی اغلب ارزان تر از خروج دائمی NAT و امن تر است.
برنامه NAT خوشه/AZ-محلی برای پهنای باند برای جلوگیری از ایجاد تنگنا.
Cache/Edge و SWR ترافیک بین منطقه ای را کاهش می دهند.
انتخاب پروتکل: HTTP/2/gRPC در داخل → اتصالات کمتر و سربار TLS وجود دارد.

15) ویژگی های iGaming/امور مالی

PCI DSS: مدار کارت (CDE) در یک شبکه جداگانه/VRF، بدون اینترنت ؛ دسترسی به فروشگاه/PSP سیاهههای مربوط تنها توسط endpoints خصوصی; ممیزیهای تغییرناپذیر (WORM/Object Lock)

KMS/Vault: کلید های تقسیم شده در هر منطقه/نام تجاری ؛ عملیات امضا (HSM) تنها از CDE بیش از mTLS در دسترس هستند.
PSP/KYC: اگر اتصال خصوصی/بازار وجود دارد - استفاده کنید ؛ در غیر این صورت، از طریق یک پروکسی قابل اعتماد با HMAC/mTLS و allowlist صریح خارج شوید.
چند اجاره: برچسب ها و سیاست های «مستاجر »/« نام تجاری» ؛ نام DNS خصوصی جداگانه و لایه های SG.

16) تولید لیست آمادگی

• طرح CIDR بدون تقاطع ؛ آماده دو پشته (IPv6).
• هاب و صحبت کرد، حمل و نقل، peering ؛ در PREM ابر ⇄ - BGP، جفت لینک پشتیبان گیری.
• همه PaaS/storages/DB - از طریق نقاط پایانی خصوصی + سیاست های نقطه پایانی.
• LB داخلی/ورودی ؛ محیط عمومی - تنها در لبه/WAF.
• DNS Split-horizon، مناطق خصوصی و حمل و نقل مشروط پیکربندی شده اند.
• خروج به طور پیش فرض «انکار» است ؛ NAT/پروکسی ها محدود شده و وارد شده اند.
• مش mTLS + SPIFFE ؛ JWT-authz در L7 ؛ Vault/ESO، اسرار کوتاه.
• NetworkPolicy/SG/NACL - «حداقل لازم»، جریان سیاهههای مربوط و دسترسی به تجزیه و تحلیل.
• جمع کننده OTel در داخل ؛ هشدار برای خروج، SLO توسط «سایت/منطقه/vpc».
• PCI/حسابرسی: سیاهههای مربوط به WORM، KMS/HSM، جداسازی CDE، دفترچه دسترسی.

17) TL ؛ دکتر متخصص

یک شبکه hub-and-spoke با یک برنامه CIDR روشن ایجاد کنید، از نقاط انتهایی خصوصی برای هر PaaS/ذخیره سازی/پایگاه داده استفاده کنید و ترافیک را فقط از طریق نقاط خروجی مدیریت شده به خارج منتقل کنید. در داخل - LB/Ingress داخلی، mTLS + SPIFFE، DNS تقسیم افق، strict NetworkPolicy/SG و تله متری از طریق OTel. برای iGaming/Finance، تقسیم بندی PCI، KMS/Vault و حسابرسی غیر قابل تغییر را اضافه کنید. خروجی PSP/KYC از طریق کانال های خصوصی و یا یک پروکسی به شدت کنترل می شود.