رمز پایگاه داده در کدام نسخه برنامه مانده است؟
یک تیم نرم افزار رمز پایگاه داده را عوض می کند، اما چند ساعت بعد یکی از کارهای زمان بندی شده متوقف می شود. سرویس اصلی رمز تازه را دریافت کرده، ولی نسخه قدیمی رمز هنوز در تنظیمات یک پردازش جانبی باقی مانده است. مسئله فقط انتخاب یک رمز قوی نیست. تیم باید بداند چه کسی راز را دریافت کرده، مدت اعتبار آن چقدر است، چگونه تمدید می شود و هنگام تغییر چه مصرف کنندگانی باید هماهنگ شوند. OpenBao برای مدیریت متمرکز رازها، کلیدها و گواهی ها امکاناتی فراهم می کند که می توانند این چرخه را روشن تر کنند.
این پروژه یک سامانه متن باز مدیریت اطلاعات حساس است. در معماری آن، روش احراز هویت، سیاست دسترسی و موتور نگهداری یا تولید راز نقش های جداگانه دارند. برنامه ابتدا هویت خود را اثبات می کند، سپس بر اساس سیاست مجاز به عملیات مشخص می شود. اینکه یک هویت بتواند وارد سامانه شود، به معنای دسترسی به همه مسیرها نیست. برای طراحی درست باید هر سه لایه را جدا بررسی کرد و ارتباط میان آنها را با نیاز واقعی سرویس تطبیق داد.
ابتدا نقشه مصرف رازها را بنویسید
پیش از نصب، فهرستی از مصرف کنندگان تهیه کنید. سرویس وب، پردازش گزارش، سامانه پشتیبان و کار استقرار معمولاً به اطلاعات یکسان نیاز ندارند. برای هر مورد مشخص کنید چه رازی لازم است، مالک آن کیست و در صورت قطع دسترسی چه اتفاقی می افتد. این فهرست کمک می کند پروژه به جابه جا کردن یک فایل بزرگ حاوی همه رمزها محدود نشود. هدف باید کاهش دامنه دسترسی و روشن شدن چرخه استفاده باشد.
در مثال فروشگاه، سرویس وب ممکن است فقط برای خواندن و ثبت سفارش به پایگاه داده دسترسی بخواهد. کار گزارش به نمای محدودتری نیاز دارد و ابزار مهاجرت ساختار پایگاه داده فقط هنگام انتشار اجرا می شود. اگر همه اینها یک اعتبارنامه مشترک بگیرند، مزیت تفکیک هویت از بین می رود. طراحی نقش های جدا در پایگاه داده و سیاست های جدا در OpenBao به هم وابسته است. محدود کردن یک طرف بدون توجه به طرف دیگر کافی نیست.
رازهای ثابت و اعتبارنامه های پویا نیز رفتار متفاوتی دارند. در حالت ثابت، برنامه مقدار ذخیره شده را می خواند و تغییر آن نیازمند هماهنگی مصرف کنندگان است. در موتورهایی که اعتبارنامه پویا را پشتیبانی می کنند، چرخه صدور، مهلت اعتبار و لغو اهمیت بیشتری پیدا می کند. انتخاب این روش باید بر اساس پشتیبانی واقعی سامانه مقصد و توان برنامه برای مدیریت تمدید انجام شود. پویایی خودکار بدون آزمون قطع و بازیابی می تواند به خطای عملیاتی تبدیل شود.
مسیرها را به مرز مسئولیت تبدیل کنید
سیاست های OpenBao روی مسیرها و قابلیت های مشخص اعمال می شوند. یک طرح نام گذاری قابل فهم، بازبینی مجوزها را آسان می کند. برای مثال، محیط آزمایش و تولید باید قابل تشخیص باشند و نام سرویس در مسیر یا ساختار سیاست روشن باشد. از قواعد بسیار باز که صرفاً راه اندازی اولیه را آسان می کنند پرهیز کنید. هر گسترش دسترسی باید توضیح دهد کدام نیاز واقعی را پاسخ می دهد.
هنگام آزمایش یک سیاست، هم حالت مجاز و هم حالت غیرمجاز را بررسی کنید. هویت سرویس سفارش باید راز خودش را دریافت کند، اما خواندن مسیر سرویس مالی باید رد شود. همچنین عملیات نوشتن، حذف و فهرست کردن را جدا آزمایش کنید. گاهی مجوزی که برای خواندن لازم تصور شده، امکان مشاهده نام رازهای دیگر را نیز ایجاد می کند. نتیجه آزمون را همراه نسخه سیاست نگه دارید تا تغییر بعدی قابل مقایسه باشد.
سیاست را مانند کد برنامه بازبینی کنید. تغییر یک الگوی مسیر ممکن است صدها هویت را تحت تأثیر قرار دهد. قبل از انتشار، فهرست هویت های وابسته و نمونه درخواست های آنها را بررسی کنید. اگر سیاستی دیگر مصرف کننده ندارد، حذف آن را پس از تأیید مالک انجام دهید. انباشته شدن سیاست های قدیمی فهم وضعیت واقعی دسترسی را دشوار می کند و احتمال استفاده دوباره از مجوزهای نامناسب را بالا می برد.
هویت برنامه از کجا می آید؟
ذخیره کردن یک توکن بسیار قدرتمند در همان فایل تنظیماتی که قرار بود پاک سازی شود، مسئله را جابه جا می کند. روش احراز هویت باید با محیط اجرا هماهنگ باشد. ماشین مجازی، خوشه کانتینری و کار کوتاه مدت استقرار ممکن است سازوکارهای متفاوتی داشته باشند. در هر مورد، نخستین مدرک هویت باید محدود، قابل تعویض و مرتبط با همان مصرف کننده باشد. مستندات روش انتخاب شده را برای نسخه نصب شده بخوانید.
دوره اعتبار توکن، امکان تمدید و شرایط لغو را صریح مشخص کنید. برنامه باید بداند چه زمانی دوباره احراز هویت کند و در صورت رد شدن تمدید چگونه واکنش نشان دهد. تکرار بی پایان درخواست با فاصله بسیار کوتاه می تواند هنگام اختلال بار اضافی ایجاد کند. تأخیر کنترل شده، ثبت خطای مناسب و هشدار به مسئول سرویس بخشی از پیاده سازی مصرف کننده است و صرف نصب OpenBao آن را برای برنامه ایجاد نمی کند.
دسترسی مدیران انسانی نیز باید از هویت سرویس جدا باشد. حساب فردی امکان پیگیری تغییر را بهتر می کند و با خروج همکار می توان همان دسترسی را لغو کرد. استفاده مشترک از یک حساب مدیریتی، تشخیص مسئول تغییر سیاست یا راز را سخت می کند. برای عملیات اضطراری، روند مشخص و آزموده داشته باشید و استفاده از آن را ثبت کنید. داشتن دسترسی اضطراری بدون بازبینی بعدی می تواند به مسیر دائمی دور زدن سیاست تبدیل شود.
قفل اولیه و بازیابی را جدی بگیرید
مستندات OpenBao میان حالت sealed و unsealed تفاوت می گذارند. در حالت قفل، سامانه نمی تواند به شکل عادی از داده رمز شده خود استفاده کند. سازوکار باز کردن قفل و محافظت از مواد بازیابی بخشی از طراحی امنیتی و دسترس پذیری است. انتخاب روش دستی یا سازوکار خودکار باید با امکانات سازمان، وابستگی های بیرونی و برنامه بازیابی سازگار باشد.
اگر باز شدن قفل به سامانه دیگری وابسته باشد، خرابی آن وابستگی را نیز در تمرین بازیابی لحاظ کنید. اگر مواد بازیابی میان چند مسئول نگهداری می شوند، نبود یکی از افراد یا تغییر شیفت نباید فرایند را مبهم کند. نگهداری این مواد در همان محل و با همان حسابی که از آن محافظت می کنند، استقلال مورد انتظار را تضعیف می کند. مسئولیت نگهداری، دسترسی و جایگزینی باید مستند باشد.
محیط توسعه برای شناخت رفتار مناسب است، اما تنظیمات ساده آن نباید بدون بررسی به تولید منتقل شود. ارتباط شبکه، گواهی TLS، ذخیره پایدار، احراز هویت مدیر و ثبت رویداد باید جدا ارزیابی شوند. پیش از انتقال اولین راز واقعی، یک چرخه کامل راه اندازی مجدد و بازیابی را با داده آزمایشی اجرا کنید. موفقیت در خواندن یک مقدار در اولین اجرا، آزمون کافی برای سامانه ای نیست که سرویس های دیگر به آن وابسته خواهند شد.
راز نباید در گزارش عیب یابی ظاهر شود
هنگام اتصال برنامه، مرز میان داده حساس و اطلاعات تشخیصی را مشخص کنید. ثبت مسیر درخواست، نتیجه عملیات و مدت پاسخ معمولاً برای عیب یابی مفید است، اما چاپ مقدار راز در گزارش برنامه می تواند یک مخزن جدید افشا ایجاد کند. فایل های خطا، ابزارهای پایش و خروجی کارهای استقرار را نیز بررسی کنید. گاهی رمز از محل اصلی حذف شده ولی در گزارش شکست همان کار باقی مانده است.
ثبت حسابرسی باید پیش از استفاده گسترده طراحی شود. مشخص کنید چه رویدادی نگهداری می شود، چه کسانی گزارش را می خوانند و چه مدت آن را حفظ می کنید. گزارش حسابرسی نیز اطلاعات حساس عملیاتی دارد و به کنترل دسترسی نیازمند است. ظرفیت ذخیره و رفتار سامانه هنگام مشکل در مسیر ثبت را با مستندات نسخه جاری تطبیق دهید و در آزمایش اختلال بررسی کنید. این بخش نباید پس از پر شدن دیسک تازه مورد توجه قرار گیرد.
برای تمرین، یک سرویس آزمایشی بسازید که فقط یک راز نمونه را می خواند. درخواست موفق، مسیر ممنوع، توکن منقضی و اختلال شبکه را اجرا کنید. سپس هم گزارش برنامه و هم گزارش حسابرسی را کنار هم بخوانید. باید بتوان بدون دیدن مقدار راز، علت هر نتیجه را تشخیص داد. این معیار عملی نشان می دهد که مشاهده پذیری و محرمانگی با هم طراحی شده اند.
تغییر رمز را با مصرف کننده آزمایش کنید
در مهاجرت واقعی، هر بار یک مصرف کننده را منتقل کنید. ابتدا دریافت راز جدید را در محیط آزمایش بررسی کنید، سپس رفتار اتصال دوباره و بازیابی پس از خطا را بسنجید. برخی برنامه ها مقدار را فقط هنگام آغاز می خوانند و برخی در طول اجرا دوباره دریافت می کنند. این تفاوت تعیین می کند تغییر راز به راه اندازی مجدد نیاز دارد یا نه. فرض یکسان درباره همه برنامه ها معمولاً باعث توقف بخشی از سامانه می شود.
یک تمرین تغییر رمز باید شامل تأیید پایان اعتبار مقدار قدیمی نیز باشد. دریافت موفق مقدار تازه کافی نیست اگر مقدار قبلی همچنان بدون محدودیت کار کند. در مقابل، لغو زودهنگام مقدار قدیمی می تواند مصرف کننده ای را که هنوز مهاجرت نکرده متوقف کند. زمان بندی گذار، فهرست مصرف کنندگان و روش برگشت باید پیش از اجرای تولید روشن باشند. مسئول پایگاه داده و مسئول برنامه باید نتیجه را با هم تأیید کنند.
موفقیت را با کاهش ابهام بسنجید
پس از راه اندازی، بپرسید آیا می توان برای هر راز مالک و مصرف کننده مشخص کرد، آیا دسترسی یک سرویس بدون اثر بر دیگران لغو می شود و آیا بازیابی در زمان مورد نیاز انجام شده است. این پرسش ها ارزش عملی بیشتری از تعداد رازهای ذخیره شده دارند. سامانه مدیریت راز زمانی مفید است که وابستگی ها و مسئولیت ها را روشن تر کند و تغییر را قابل آزمون سازد.
بازبینی دوره ای باید هویت های بلااستفاده، سیاست های گسترده، توکن های نامتناسب و مصرف کنندگان قدیمی را پوشش دهد. هر سرویس تازه باید از همان ابتدا وارد نقشه مالکیت شود. با این روش OpenBao به بخش قابل نگهداری زیرساخت تبدیل می شود و تیم می تواند تغییر اعتبارنامه را مانند یک عملیات مهندسی قابل پیش بینی انجام دهد، با شواهدی که هم امنیت و هم استمرار سرویس را نشان می دهند.
