یافتن و حفاظت از داده‌های حساس در APIها چگونه است؟

داده‌ها سوخت اصلی اینترنت مدرن هستند. APIها برای ارتباط و ارائه مزایای شگفت‌انگیزی که در اینترنت مدرن مشاهده کرده‌ایم، به داده نیاز دارند. با این حال، این داده‌ها صرفاً ۱ و ۰ ساده نیستند. اغلب نمایانگر هویت افراد و گروه‌ها هستند و خواسته‌ها، ویژگی‌ها و اطلاعات شخصی آن‌ها را منعکس می‌کنند.

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

PII و داده‌های حساس چیستند؟

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

PII توسط سازمان‌ها و نهادهای نظارتی مختلف تعریف شده است. در ایالات متحده، موسسه ملی استاندارد و فناوری (NIST) PII را اینگونه تعریف می‌کند:

“اطلاعات شخصی شناسایی‌پذیر: هر نمایشی از اطلاعات که اجازه می‌دهد هویت فردی که اطلاعات به او مربوط است، به‌طور مستقیم یا غیرمستقیم استنباط شود.”

در اروپا، PII تحت GDPR به طور گسترده به عنوان «داده شخصی» تعریف می‌شود:

“داده شخصی به هر اطلاعاتی گفته می‌شود که به یک فرد شناسایی شده یا قابل شناسایی مرتبط باشد (‘موضوع داده’)؛ فرد قابل شناسایی کسی است که می‌توان او را به‌طور مستقیم یا غیرمستقیم شناسایی کرد، به‌ویژه با اشاره به شناسه‌ای مانند نام، شماره شناسایی، داده موقعیت، شناسه آنلاین یا یک یا چند عامل خاص مرتبط با هویت فیزیکی، فیزیولوژیکی، ژنتیکی، ذهنی، اقتصادی، فرهنگی یا اجتماعی آن فرد…”

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

UpGuard تعریف ساده‌ای از داده‌های حساس ارائه می‌دهد:

“داده‌های حساس، اطلاعات محرمانه‌ای هستند که باید ایمن نگه داشته شوند و از دسترسی افراد خارجی محفوظ بمانند مگر اینکه اجازه دسترسی داشته باشند.”

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

ملاحظات قانونی

یک نکته مهم این است که حفاظت از این داده‌ها فقط یک کار پسندیده نیست — در بسیاری موارد، قانونی است. برخی داده‌ها باید حتماً محافظت شوند، مانند اطلاعات کارت اعتباری تحت PCI DSS، در حالی که داده‌های دیگر مانند جنسیت، هویت، مکان و غیره تحت قوانین مختلف قرار دارند که ممکن است در نگاه اول شفاف نباشند.

در اتحادیه اروپا، مقررات عمومی حفاظت از داده‌ها (GDPR) سند نظارتی است که این داده‌ها را پوشش می‌دهد. GDPR نه تنها مشخص می‌کند چه چیزی PII و داده حساس است، بلکه مکانیزم‌های اجرایی شدیدی نیز دارد. برای نقض‌های جدی، جریمه‌ها می‌توانند تا ۴٪ از گردش مالی جهانی یا تا ۲۰ میلیون یورو، هرکدام که بالاتر باشد، باشد. برای تخلفات جزئی، جریمه‌ها می‌توانند تا ۲٪ از گردش مالی جهانی یا ۱۰ میلیون یورو — مجدداً هرکدام که بالاتر باشد — باشند.

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

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

اعتماد برند و امنیت

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

این موضوع را قبلاً دیده‌ایم — داستان‌هایی از شرکت‌هایی که پس از نقض داده‌ها تعطیل شدند بسیار رایج است. حتی اگر شرکت‌ها ادامه دهند، اغلب با از دست دادن قابل توجه مشتری و درآمد مواجه می‌شوند.

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

یافتن داده‌های حساس در APIها: APIها نشت دارند

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

در نتیجه، نیمی از نبرد یافتن داده‌های حساس در معرض افشا است.

اسکن و کشف خودکار

با پذیرش گسترده خدمات امنیتی مبتنی بر AI و LLM، اسکن و کشف آسیب‌پذیری‌ها هرگز آسان‌تر نبوده است. راهکارهایی مانند Salt Security ارائه‌دهنده ابزارهای خودکار برای شناسایی Endpointهای در معرض خطر و ضعف‌های امنیتی هستند.

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

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

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

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

طبقه‌بندی داده‌ها

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

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

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

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

حفاظت از داده‌ها

پیاده‌سازی احراز هویت و مجوز مناسب

احراز هویت و مجوز مناسب، عامل کلیدی در امنیت داده‌ها هستند. اساساً، احراز هویت اطمینان می‌دهد که کسی که به سیستم دسترسی دارد همان کسی است که ادعا می‌کند، و مجوز تضمین می‌کند که حق دسترسی به داده‌ها را دارد.

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

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

استفاده از رمزگذاری کافی

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

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

دو نوع رمزگذاری وجود دارد که سازمان‌ها باید از آن‌ها آگاه باشند:

1. رمزگذاری در حین انتقال (In Transit): این رمزگذاری به ارسال‌کننده و گیرنده اجازه می‌دهد داده را رمز و بازکرده کنند تا اگر داده‌ای در مسیر به دست کسی رسید، قابل استفاده نباشد.

2. رمزگذاری در حال استراحت (At Rest): داده‌های ذخیره شده نیز باید رمزگذاری شوند تا حتی اگر افشا شوند، به دلیل هزینه اقتصادی و منابع بالا، برای فرد مهاجم بی‌فایده باشند یا حداقل تا زمان تغییر گذرواژه‌ها و داده‌های جایگزین بی‌فایده باشند.

انتخاب عدم جمع‌آوری

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

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

صنعت فناوری سال‌ها داده‌ها را به‌عنوان طلای دیجیتال می‌دید. واقعیت این است که رمزگذاری و سایر تلاش‌های امنیتی هزینه دارند و تنها نگه داشتن داده به این دلیل که “ممکن است ارزشمند باشد” به ویژه وقتی داده متعلق به کاربران است، تنها هزینه و ریسک اضافی ایجاد می‌کند.

حفاظت از داده‌های حساس در APIها

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