فراخوانی برای امنیت داده ها

در طول دو دهه گذشته، ما شاهد بوده ایم که امنیت بیشتر و بیشتر گران شده است و به نسل بعد از نسل عمیق تر می شود – از سخت افزار گرفته تا شبکه، سرور، کانتینر و اکنون بیشتر و بیشتر به کد.

باید روی داده ها متمرکز شود. اولین.

مرز بعدی در امنیت داده ها، به ویژه داده های حساس است. داده‌های حساس، داده‌هایی هستند که سازمان‌ها نمی‌خواهند به بیرون درز یا نقض شوند. این شامل PHI، PII، PD و داده های مالی است. نقض داده های حساس جریمه های واقعی را به همراه دارد. برخی از آنها ملموس هستند، مانند جریمه های GDPR (10 میلیون یورو یا 2 درصد از درآمد سالانه)، جریمه های FTC (به عنوان مثال 150 میلیون دلار در برابر توییتر) و هزینه های قانونی. سپس هزینه‌های نامشهود مانند از دست دادن اعتماد مشتری (مثلاً داده‌های افشا شده Chegg متعلق به 40 میلیون کاربر)، درد بازسازی و بدتر از آن وجود دارد.

>>موضوع ویژه ما را از دست ندهید: دستور کار CIO: نقشه راه 2023 برای رهبران فناوری اطلاعات.<<

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

اگر داده ها را مرکز جهان امنیت قرار دهید چه اتفاقی می افتد؟

یکی از ارزشمندترین دارایی‌هایی که سازمان‌ها می‌خواهند از آن محافظت کنند، داده‌ها است و نقض گسترده داده‌ها و نشت داده‌ها اغلب اتفاق می‌افتد. زمان تحول جدیدی در امنیت سایبری فرا رسیده است: امنیت داده ها.

داده ها متفاوت است

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

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

چالش امنیت داده این است که داده ها تقریباً بی نهایت در سیستم ها جریان دارند، به ویژه در یک زیرساخت بومی ابری. در یک دنیای ایده آل، ما باید بتوانیم داده ها و خطرات و آسیب پذیری های مرتبط با آن را در هر سیستم و در هر زمان دنبال کنیم. در واقع ما با این موضوع فاصله زیادی داریم.

امنیت داده اول باید در کد شروع شود. این بدان معناست که با توسعه دهندگان: Shift سمت چپ. طبق گفته GitLab، 57 درصد از تیم های امنیتی قبلاً امنیت را به سمت چپ تغییر داده اند یا برای امسال برنامه ریزی می کنند. از ابتدای سفر شروع کنید و هنگام کدنویسی، داده ها را ایمن کنید.

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

بنابراین یک رویکرد امنیت داده اول باید شامل سه جزء باشد: 1) نمی تواند مسئولیت امنیتی دیگری باشد. 2) باید زمینه مالکیت را درک کند. 3) در برابر خطاهای منطق تجاری سفارشی محافظت می کند (هر نقض شامل یک اشکال نیست).

مسئولیت امنیتی دیگری نیست

امنیت در مورد کاهش خطر است. افزودن یک ابزار یا فروشنده جدید برخلاف این اصل اساسی است. همه ما SolarWinds را در ذهن داریم، اما دیگران هر روز ظاهر می شوند. داشتن یک ابزار جدید که با محیط تولید شما یکپارچه می شود، نه تنها برای تیم امنیتی، بلکه برای تیم SRE/Ops یک درخواست بزرگ است. انجام کشف داده‌ها در زیرساخت‌های تولید به معنای نگاه کردن به ارزش‌های واقعی، داده‌های مشتری بالقوه است – اساساً آنچه ما در وهله اول سعی در محافظت از آن داریم. شاید بهترین راه برای تبدیل نشدن به یک خطر دیگر این باشد که به سادگی به زیرساخت ها و داده های حساس دسترسی نداشته باشید.

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

به همان اندازه که امنیت تغییر چپ سنتی ارزشمند است، رویکرد امنیتی اول داده ارزش بیشتری را برای سازمان ایجاد می کند.

زمینه مالکیت

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

چرا ما این داده ها را ذخیره می کنیم؟ دلیل تجاری برای به اشتراک گذاری این داده ها با این شخص ثالث چیست؟ اینها سوالاتی است که سازمان ها باید در یک نقطه خاص به آنها پاسخ دهند. امروزه این سوالات به طور فزاینده ای توسط تیم های امنیتی، به ویژه در محیط های بومی ابری بررسی می شود. پاسخ به آنها، و شناسایی خطرات مرتبط، بدون افشای “مالکیت” تقریبا غیرممکن است.

با انجام امنیت داده اول از نقطه نظر کد، دسترسی مستقیم به اطلاعات متنی عظیم داریم – به ویژه، چه زمانی چیزی معرفی شده است و توسط چه کسی. راه حل های DSPM به سادگی نمی توانند این زمینه را با نگاه انحصاری به فروشگاه های داده تولید فراهم کنند.

اغلب سازمان ها بر «ارزیابی دستی» تکیه می کنند. آنها پرسشنامه هایی را برای کل تیم مهندسی ارسال می کنند تا بفهمند کدام داده های حساس، چرا و چگونه پردازش می شوند. توسعه دهندگان از این پرسشنامه ها متنفرند و اغلب بسیاری از سوالات را درک نمی کنند. نتایج ضعیف امنیت داده ها قابل پیش بینی است.

مانند بسیاری از چیزهای “فنی”، موثرترین رویکرد، خودکار کردن کارهای خسته کننده با فرآیندی است که با حداقل یا بدون اصطکاک وارد جریان های کاری موجود می شود، اگر در مورد امنیت داده ها، به ویژه در مقیاس جدی هستید.

منطق تجاری سفارشی

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

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

اما آیا کد کافی است؟

شروع یک سفر امنیتی داده اول از کد بسیار منطقی است، به ویژه از آنجا که بسیاری از بینش های یافت شده در آنجا در هیچ جای دیگری قابل دسترسی نیستند (اگرچه این درست است که برخی از اطلاعات ممکن است گم شده باشند و فقط در سطح زیرساخت یا تولید یافت شوند.)

تطبیق اطلاعات بین کد و تولید بسیار دشوار است، به خصوص با وجود دارایی های داده ای که در همه جا جریان دارند. Airbnb نشان می دهد که چقدر می تواند پیچیده باشد. خبر خوب این است که با تغییر زیرساخت به عنوان کد (IaC)، می‌توانیم اتصالات را در سطح کد برقرار کنیم و از برخورد با آشتی دردناک اجتناب کنیم.

با توجه به چالش‌های مرتبط با امنیت و داده‌ها، هر راه‌حل امنیتی باید حداقل «آگاه از داده» و احتمالاً «اول از داده» در هر لایه‌ای از پشته که در آن وجود دارد، شود. ما می‌توانیم مدیریت وضعیت امنیت ابری را ببینیم (CSPM) ) ترکیب محلول ها با DSPM، اما آیا کافی است؟

Guillaume Montard یکی از بنیانگذاران و مدیرعامل Bearer است.