رمزهای آلمانی، تلگرام‌ها و حاکمیت داده در فضای ابری بومی

به گزارش از وبسایت cncf 📌

یک درس از سال ۱۹۱۷

در ژانویه ۱۹۱۷، آلمان یک تلگرام محرمانه به مکزیک فرستاد. پیشنهاد این بود: اگر در جنگ علیه ایالات متحده وارد شوید، می‌توانید Texas، Arizona و New Mexico را پس بگیرید. آلمانی‌ها با دقت عمل کردند و پیام را در یک cipher پنهان کردند. کابل‌های فرااقیانوسی خودشان قطع شده بود، بنابراین ناچار شدند پیام را از تنها مسیر در دسترس بفرستند؛ از خطوطی که از قلمرو بریتانیا عبور می‌کرد و بخشی از آن هم روی یک کابل آمریکایی منتقل می‌شد. این کابل از نظر قراردادی خصوصی محسوب می‌شد، و از آنجا که پیام رمزگذاری شده بود، چنین برداشتی تقویت می‌شد. اما Britain بی‌سروصدا این خطوط را شنود می‌کرد. گروهی از رمزگشاها در Admiralty، در Room 40، کل پیام را خواندند. شش هفته بعد، این ماجرا روی صفحه اول تمام روزنامه‌های آمریکا بود. مدت زیادی نگذشت که ایالات متحده وارد جنگ شد.

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

یک چالش مدرن برای sovereignty

این درسِ مربوط به یک قرن پیش، امروز هم به شکلی بسیار مدرن خود را نشان می‌دهد. اوایل امسال گزارش شد که یک US hyperscaler اسنادی را در اختیار مجلس آمریکا قرار داده که به دو نهاد نظارتی هلندی تعلق داشته است؛ از جمله ایمیل‌ها، صورت‌جلسه‌ها و دعوت‌نامه‌های جلسه. این افراد همان کسانی هستند که وظیفه‌شان اجرای Digital Services Act اروپا علیه شرکت‌های فناوری آمریکایی است. گفته شد این اسناد با نام افراد و بدون redaction تحویل داده شده‌اند؛ در عمل یعنی فهرستی آماده از افرادی که در حال پاسخ‌گو کردن غول‌های فناوری آمریکا هستند. هرچند جزئیات ماجرا هرچه باشد، این اتفاق تصویر data sovereignty را به شکلی تغییر می‌دهد که باید جدی به آن فکر کرد.

مکانیزم اصلی در این میان، US CLOUD Act است. این قانون می‌تواند یک شرکت آمریکایی را مجبور کند داده‌ها را تحویل بدهد، حتی اگر آن داده‌ها روی خاک اروپا ذخیره شده باشند. در testimony رسمی در برابر Senate فرانسه، وکیل یکی از ارائه‌دهندگان خدمات نتوانست تضمین کند که داده‌های فرانسویِ نگهداری‌شده در data centerهای اروپایی از دسترسی پنهان آمریکا در امان هستند. بنابراین جمله‌ی «سرورهای ما در Frankfurt هستند» در عمل معنای چندانی ندارد.

این همان تمایزی است که جامعه cloud native بارها به آن بازمی‌گردد: data residency با data sovereignty یکی نیست. residency فقط می‌گوید بایت‌ها از نظر فیزیکی کجا قرار دارند؛ اما sovereignty مشخص می‌کند چه کسی از نظر حقوقی بر آن‌ها دسترسی و اختیار دارد. Frankfurt فقط اولی را به شما می‌دهد. حوزه قضاییِ operator دومی را تعیین می‌کند، و این حوزه همراه با operator جابه‌جا می‌شود، نه با postcode. 🌍

مسئله‌ای ساختاری، نه وابسته به یک vendor

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

انتخاب یک operator «بهتر» در همان حوزه قضایی، شما را از همان موقعیت خارج نمی‌کند. هر وابستگی‌ای که کنترلش با شما نیست، در واقع ریسکی است که فقط پرداختش را عقب انداخته‌اید. این خطر را همان روزی حس نمی‌کنید که قرارداد را امضا می‌کنید؛ روزی آن را حس می‌کنید که شرایط عوض می‌شود، قیمت بالا می‌رود، subpoena می‌رسد یا همان تأمین‌کننده‌ای که کل stack شما روی آن بنا شده، ناگهان اعلام می‌کند use case شما دیگر اولویت نیست. آن هزینه از ابتدا وجود داشت، فقط پرداختش برای بعد برنامه‌ریزی شده بود. ⏳

انتخاب آگاهانه برای زیرساخت

ما نمی‌گوییم cloud خودتان را جمع کنید و به یک shed منتقل شوید. چنین کاری هم از نظر عملی و هم از نظر مهندسی، تصمیم عاقلانه‌ای نیست و مزیت واقعی managed serviceها را هم از بین می‌برد. توصیه ما این است که ببینید کدام هزینه‌ها را به تعویق انداخته‌اید و آیا واقعاً حاضر هستید آن‌ها را بپذیرید یا نه.

برای چیزهایی که اهمیت چندانی ندارند، convenience انتخاب درستی است: اجاره کنید، برون‌سپاری کنید و دیگر نگرانش نباشید. اما برای بخش‌هایی که واقعاً حساس‌اند، ماجرا فرق می‌کند؛ داده‌ای که افشای آن می‌تواند یک career را نابود کند، سیستمی که نهادهای نظارتی درباره‌اش سؤال خواهند کرد، یا لایه‌ای که کل کسب‌وکار شما از آن عبور می‌کند. در این موارد، ownership و sovereignty ارزشِ آن اصطکاک اضافه را دارند. ✨

این همان استدلال آرام و کم‌هیاهو برای open source و زیرساختی است که بتوانید خودتان آن را اجرا کنید؛ نه از سر ideology، بلکه برای آزادیِ ساده و قابل‌اعتمادِ دانستن اینکه داده‌هایتان کجا هستند، چه کسی می‌تواند به آن‌ها دسترسی داشته باشد و اگر رابطه کاری تیره شد، چه اتفاقی می‌افتد.

جایگاه cloud native

این نوع آزادی امروز قابل ساختن است و بخش زیادی از آن همین حالا در landscape مربوط به CNCF وجود دارد. فناوری‌های cloud native با تأکید بر portability، open standards و اجزای interoperable، این انتخاب‌های استقرار را عملی می‌کنند. برای هر سیستم حیاتی، چهار پرسش مهم است:

اول: کجا اجرا می‌شود؟ Container orchestration platformهایی مثل Kubernetes یک بستر استقرار یکسان بین public cloud، زیرساخت خصوصی و حتی regional یا sovereign cloud providerها فراهم می‌کنند. یک workload که یک‌بار بسته‌بندی شده باشد، می‌تواند با همان manifestها روی یک hyperscaler، در data center خودتان یا روی یک sovereign cloud اجرا شود.

دوم: چه کسی آن را می‌بیند؟ OpenTelemetry به سازمان‌ها اجازه می‌دهد traces، metrics و logs را با open standards جمع‌آوری کنند و آن‌ها را به back-end دلخواه و میزبانی‌شده توسط خودشان بفرستند؛ در نتیجه تصویر عملیاتی سامانه در جایی می‌ماند که خودشان بتوانند آن را export کنند.

سوم: چه کسی policy را تعریف می‌کند؟ Open Policy Agent (OPA) تصمیم‌های دقیقِ authorization و governance را در policyهایی قرار می‌دهد که مالک آن هستید و نسخه‌بندی می‌کنید؛ این سیاست‌ها به‌صورت یکپارچه در سراسر stack اعمال می‌شوند، بنابراین قواعد همراه با code شما به هر محیطی که اجرا شود منتقل می‌شوند.

چهارم: APIها چگونه govern می‌شوند؟ API gatewayهایی که از open standards مانند OpenTelemetry، OpenAPI، OAuth و Open Policy Agent پشتیبانی می‌کنند، به سازمان‌ها امکان می‌دهند سیاست‌های یکسانِ governance و security را اعمال کنند و در عین حال کنترل محل استقرار data planeها را حفظ کنند. چنین gatewayی می‌تواند policy مربوط به regional data sovereignty را در استقرارهای self-managed، cloud، hybrid و containerized از یک control plane واحد اعمال کند.

خود این فهرست به اندازه چیزی که نشان می‌دهد اهمیت ندارد: این‌که آزادیِ بی‌دردسرِ دانستن محل داده‌ها، افراد مجاز به دسترسی و پیامدهای به‌هم‌خوردن رابطه، همین حالا در دسترس است؛ آن هم بر پایه software متن‌بازِ成熟 که می‌توانید هرجا خواستید اجرا کنید. 🛠️

راحتی در برابر کنترل

راحتی عملیاتی بی‌دلیل ارزشمند نیست و cloud native هم زحمت مهندسی لازم برای اداره زیرساخت را از بین نمی‌برد. اداره کردن زیرساخت خودتان، نسبت به اجاره کردن زیرساخت دیگران، کار بیشتری می‌طلبد؛ البته تا صبحی که دیگر این‌طور نباشد. در نهایت، data sovereignty کمتر به محل قرار گرفتن زیرساخت مربوط است و بیشتر به این برمی‌گردد که چه کسی آن را کنترل می‌کند، کدام چارچوب‌های حقوقی به آن دسترسی دارند و هنگام تغییر نیازها چه میزان انعطاف برای خودتان نگه داشته‌اید.

اگر لایه حیاتی شما روی زیرساختی اجرا می‌شود که کنترلش با شما نیست، در واقع پذیرفته‌اید که شخص دیگری می‌تواند نامه‌های شما را بخواند. اما اگر آن لایه open source باشد، بدون black box اجرا شود و بتوانید آن را هرجا که خواستید بالا بیاورید، آنگاه wires واقعاً در اختیار شماست. 🔐