چگونه ارسال‌های فرم عمومی را به شبکه خصوصی وارد کنیم

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

از همان‌جا شروع کنید که ارسال فرود می‌آید

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

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

curl --silent --fail \
  --cert /etc/importer/client.crt --key /etc/importer/client.key \
  "https://intake.corp.internal/api/pending?limit=20" \
  -o /var/lib/importer/pending.json

به واردکننده فقط همان اختیاری را بدهید که لازم دارد

فرایند وب عمومی و هویتی که در برنامه داخلی می‌نویسد باید دو موجودیت متفاوت باشند. سرور عمومی فقط به این دلیل که باید داده فرم را تحویل دهد به مدیریت داخلی نیاز ندارد، و یک حساب مشترک برای هر دو سمت هر باگ وب را به یک نوشتن داخلی تبدیل می‌کند. به کارگر اعتبارنامه خودش را بدهید، آن را به همان یک عملیات واردات محدود کنید و ثبت کنید کدام موجودیت هر واردات را انجام داده است. همین تفکیک است که مرز تونل را معنادار می‌کند و نه تزئینی.

همچنین محدود کنید کارگر از کدام منبع می‌تواند بخواند. اگر پیاده‌سازی از یک صف یا سرویس انتقال استفاده می‌کند، آن سرویس احراز هویت و سیاست دسترسی خودش را نگه می‌دارد، چون VPN هیچ چیزی را درون محموله احراز هویت نمی‌کند.

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

پیش از آنکه چیزی در داخل تغییر کند اعتبارسنجی کنید

فیلدهای فرم عمومی تا زمانی که خلافش ثابت شود متن تحت کنترل مهاجم هستند، و راهنمای اعتبارسنجی ورودی OWASP دقیقاً به همین دلیل جریان‌های بک‌اند را در زمره منابع غیرقابل اعتماد می‌آورد. انتقال رمزنگاری‌شده می‌گوید بایت‌ها سالم رسیده‌اند، نه اینکه یک درخواست مجاز را توصیف می‌کنند. پیش از هر گام دارای امتیاز، تجزیه و اعتبارسنجی کنید تا یک ردیف بد هرگز به مسیر کدی نرسد که می‌تواند عمل کند.

فیلدهای مجاز، قالب‌هایشان، اندازه‌هایشان و قواعد کسب‌وکاری را که باید برقرار باشند تعریف کنید. یک تاریخ می‌تواند از نظر قالب درست باشد و باز هم برای عملیات درخواستی نادرست باشد، و محموله‌ای که یک حساب داخلی یا وضعیت تأیید را نام می‌برد نباید بتواند هیچ‌کدام را به خودش بدهد.

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

نقطه تلاش دوباره را روی یک عملیات بسازید

اگر رکورد submission-1042 دو بار کشیده شود چون اولین تأیید از دست رفته است، کارگر به راهی پایدار برای شناختن رکورد منبع و نتیجه تثبیت‌شده آن نیاز دارد. زمان‌بندی‌ای که کار را یک بار اجرا می‌کند ثابت نمی‌کند که هر ردیف یک بار اعمال شده است. تحویل تکراری عادی است، پس طراحی باید آن را جذب کند.

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

سپس آن را با سه فایل آزمایشی اثبات کنید: یک ردیف معتبر، یک ردیف بدشکل و همان شناسه منبع کنترل‌شده که دو بار تحویل داده می‌شود. هر یک از همان نقطه پایانی‌ای می‌گذرد که کارگر استفاده می‌کند.

for f in fixtures/valid-submission.json fixtures/bad-date.json; do
  curl --silent --fail --cert /etc/importer/client.crt \
    -X POST --data @"$f" https://intake.corp.internal/api/records
done
curl --silent --fail --cert /etc/importer/client.crt \
  -X POST --data @fixtures/valid-submission.json https://intake.corp.internal/api/records

دو ردیف اول باید در دو وضعیت داخلی متفاوت پایان یابند، و ردیف سوم باید شناسه‌ای را که پیش‌تر برای آن رکورد منبع تثبیت شده بازگرداند، نه اینکه شناسه دومی بسازد. هر چیز دیگری یعنی واردات هنوز تکرارپذیر نیست.