بعدتر روی Raja PAM از سمت بک اند کار کردم و از محصولات PAM و DLP ساخته شده در راژاکو برای سازمان های بزرگ، از جمله بانک ها، پشتیبانی کردم. این تجربه نرم افزاری را نشانم داد که در آن پایداری، دسترسی، امنیت، پشتیبانی و فشار سازمانی به شکلی مهم می شوند که نرم افزار مصرفی کمتر تجربه می کند.
PAM در عمل یعنی چه
Privileged Access Management فقط یک feature نیست؛ یک discipline است. یعنی کنترل اینکه چه کسی به چه سیستمی دسترسی دارد، ثبت کاری که انجام می دهد و اطمینان از اینکه دسترسی در لحظه بحران قابل قطع شدن است. برای یک بانک، compromised admin session فقط یک ticket نیست؛ ممکن است incident قانونی باشد.
کار روی بک اند PAM یعنی ساخت audit trailهایی که قابل دستکاری نباشند، session recording که جزئیات کاربر را ثبت کند و policyهایی که بتوانند سلسله مراتب سازمانی پیچیده را بیان کنند. هر endpoint باید فرض کند caller ممکن است compromised باشد.
پشتیبانی نوع دیگری از مهندسی است
پشتیبانی سازمانی فشار را عوض کرد. وقتی deployment یک بانک خراب می شود، rollback windowی از جنس «بعدا بررسی می کنیم» وجود ندارد. تماس هست، ticket با priority بحرانی هست و مشتری باید به تیم compliance خودش جواب بدهد.
- بازتولید issueهایی که فقط در topology شبکه خاص رخ می دهند
- debug کردن configurationهایی که مشتری بدون اطلاع تغییر داده است
- patch و verify کردن fix زیر محدودیت زمانی بدون جا برای حدس
پشتیبانی به من یاد داد نرم افزار وقتی ship می شود تمام نشده؛ وقتی اولین incident واقعی را تاب می آورد تازه معنی پیدا می کند. این نگاه، نوشتن error message، ساختار log و میزان اعتماد به فرض های خودت را تغییر می دهد.
فشار سازمانی اولویت ها را تغییر می دهد
در startup یا پروژه شخصی، معمولا سرعت را بهینه می کنی. در سازمان، predictability مهم تر است. featureای که ۹۹ درصد مواقع کار می کند وقتی آن یک درصد یعنی بانک نمی تواند کارش را ادامه دهد کافی نیست.
این فشار همه چیز را شکل می دهد: تست چقدر کافی است، release چطور stage می شود، درباره known issue چطور حرف می زنی و چطور تصمیم می گیری چه چیزی الان fix شود و چه چیزی به عنوان limitation مستند شود. کمتر هیجان انگیز از ساختن چیز جدید است، اما reliability همان جا ساخته می شود.
چیزی که از کار سازمانی ماند
عادت فکر کردن به failure mode قبل از وقوع. غریزه verify کردن قبل از فرض گرفتن. فهم اینکه خیلی از مسئله های نرم افزار فنی نیستند؛ mismatch بین استفاده ای هستند که توسعه دهنده انتظار داشته و استفاده ای که واقعا رخ می دهد. کار سازمانی این mismatch را غیرقابل چشم پوشی کرد.