داده پوشانی یا پوشش‌دهی داده (به انگلیسی: data masking)[۱][۲] یا مبهم‌سازی داده (به انگلیسی: data obfuscation)[۳] فرایند پنهان کردن داده اصلی با محتوای اصلاح شده (کاراکترها یا داده‌های دیگر) می‌باشد.

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

نگرانی اصلی از دیدگاه یک حاکمیت شرکتی[۴] این است که در این محیط‌های غیرتولیدی، کارکنان برای کار کردن با اطلاعات مشمول در داده‌های تولیدی، همیشه پاکسازی امنیتی نشده‌اند. این عمل نشان‌دهنده یک حفره امنیتی است که می‌توان داده‌ها را با استفاده از کارکنان غیرمجاز کپی برداری کرد و اقدامات امنیتی مرتبط با کنترل‌های سطح تولیدی استاندارد را به راحتی دور زد؛ که نشان‌دهنده یک نقطه دسترسی برای نقض امنیت داده‌ها می‌باشد.

رویه کلی داده پوشانی در یک سطح سازمانی باید به شدت با روش مدیریت آزمون[۵][۶] و روش پژوهشی ضمنی همراه باشد و باید فرایندهایی را برای توزیع زیرمجموعه‌های داده آزمایشی پوشش‌دهی شده دربرگیرد.[۷][۸][۹]

پیش زمینه ویرایش

داده های مربوط به پوشش‌دهی و مبهم‌سازی باید در چندین سطح معنایی ثابت باشند:

  1. داده‌ها باید برای منطق نرم‌افزار معنادار باقی بمانند. به عنوان مثال، اگر قرار باشد عناصر مربوط به آدرس‌ها دچار مبهم‌سازی شوند و شهرها و حومه شهرها با شهرها و حومه شهرهای دیگری جایگزین شوند، در صورتی که در داخل نرم‌افزار ویژگی‌ای وجود دارد که می‌تواند کدپستی را تأیید کرده یا آن را جستجو کند، باید آن عملکرد بدون خطا اجازه انجام یابد و مطابق انتظار عمل کند. همین مسئله برای بررسی اعتبار سنجی الگوریتم کارت اعتباری و اعتبارسنجی شماره تأمین اجتماعی نیز صادق است.
  2. داده‌ها باید تغییرات کافی را متحمل شوند تا مشخص نباشد که داده‌های پوشش‌دهی از منبع داده‌های تولیدی هستند. به‌طور مثال، بدیهی است که امکان دارد در یک سازمان ۱۰ مدیر ارشد وجود داشته باشد که همه آنها بیش از ۳۰۰ هزار دلار درآمد دارند. اگر محیط آزمون سیستم منابع انسانی سازمان نیز شامل ۱۰ هویت در همان دامنه درآمدی باشد، سایر اطلاعات می‌تواند با هم ترکیب شده تا یک هویت واقعی مهندسی معکوس شود. از دیدگاه نظری، اگر داده‌ها به صورت بدیهی پوشش‌دهی یا مبهم‌سازی شوند، برای کسی که قصد یک نقض داده را دارد، منطقی خواهد بود که فرض کند اگر اطلاعاتی از هویت‌ها در مجموعه داده‌های تولیدی وجود داشته باشد، می‌تواند داده هویتی را مهندسی معکوس کند. بر این اساس، مبهم‌سازی یا پوشش‌دهی مجموعه‌داده به گونه‌ای اعمال می‌شود که از حفاظت هویت و سوابق داده‌های حساس اطمینان حاصل شود – نه فقط عناصر داده‌های فردی در فیلدهای گسسته و جدوال.
  3. ممکن است لازم باشد مقادیر پوشش‌دهی در بین چندین پایگاه داده در یک سازمان هنگامی که هرکدام از پایگاه‌های داده شامل عناصرداده خاص پوشش‌دهی هستند، با یکدیگر سازگار باشند. نرم‌افزارها ممکن است ابتدا به یک پایگاه داده دسترسی داشته باشند و بعداً به یکی دیگر دسترسی پیدا کنند تا اطلاعات مربوط به مکانی که کلید خارجی پوشش‌دهی شده‌است را بازیابی کنند (به عنوان مثال یک نرم‌افزار مرکز تماس در ابتدا داده‌هایی را از پایگاه داده اصلی مشتری جمع‌آوری کرده و بسته به وضعیت، متعاقباً به یکی از پایگاه‌های داده باقی مانده با محصولات مالی بسیار متفاوت دسترسی پیدا می‌کند) این امر مستلزم این است که پوشش‌دهی اعمال شده قابل تکرار باشد (همیشه همان ورودی برای الگوریتم پوشش‌دهی، همان مقدار خروجی را به‌دست دهد) اما قادر به مهندسی معکوس برای بازگشت مقدار اصلی نباشد. قیود اضافی ذکر شده در مورد (۱) بالا، ممکن است بسته به عنصر (یا عناصر) داده‌ها نیز بکار رود. در صورت استفاده از مجموعه‌های الفبا مختلف در پایگاه‌های داده‌ای که باید در این سناریو به یکدگیر متصل شوند، نیاز خواهد شد تا یک طرح کلی از تبدیل مقادیر اصلی به یک نمایه مشترک، توسط خود الگوریتم پوشش‌دهی یا قبل از استناد به الگوریتم گفته‌شده، مورد استفاده قرار گیرد.

روش‌ها ویرایش

جانشینی ویرایش

جانشینی یکی از مؤثرترین روش‌ها برای اعمال داده پوشانی می‌باشد و توانایی حفظ شکل و حس معتبر سوابق داده را دارد.

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

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

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

جابجایی ویرایش

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

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

انحراف معیار عددی و زمانی ویرایش

روش انحراف معیار عددی برای استفاده در زمینه‌های اطلاعات مالی و زمانی‌محور بسیار مفید است. به‌طور مؤثر، روشی که از این نوع پوشش‌دهی استفاده می‌کند، هنوز هم می‌تواند یک دامنه معنی‌دار در یک مجموعه داده‌های مالی مانند فهرست دستمزد باقی بگذارد. اگر انحراف معیار به کار رفته در حدود %۱۰-/+ باشد، هنوز هم داده‌های بسیار معنی‌داری از نظر محدوده حقوق‌های پرداختی به دریافت کنندگان وجود دارند.

همین امر در مورد اطلاعات زمانی نیز صادق است. اگر مجموعه داده‌های کلی نیاز به حفظ یکپارچگی داده‌های جمعیت‌شناسی و بیم‌سنجی داشته باشند، با استفاده از اعمال یک انحراف معیار عددی تصادفی از ۱۲۰-/+ روز به فیلدهای زمانی، توزیع زمانی حفظ خواهد شد اما هنوز هم مانع از ردیابی به یک عضو شناخته شده بر اساس زمان واقعی یا تاریخ تولد یا مقدار زمانی شناخته شده از هر سابقه‌ای که پوشش‌دهی شده‌است، می‌شود.

رمزگذاری ویرایش

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

به تازگی، مسئله رمزگذاری داده‌ها ضمن حفظ خصوصیات هویت‌ها، به رسمیت شناخته شده و محبوبیت جدیدی را در میان فروشندگان و دانشگاهیان به دست آورده‌است. چالش جدیدی برای الگوریتم‌هایی با نام FPE (رمزگذاری حفظ ساختار) به وجود آمده‌است. آنها بر اساس روش الگوریتمی AES مورد قبول واقع می‌شوند که باعث می‌شود تا توسط مؤسسه ملی فناوری و استانداردها یا NIST تشخیص داده شوند.[۱۰]

ابطال یا حذف ویرایش

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

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

پنهان سازی ویرایش

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

این روش معمولاً برای داده‌های کارت اعتباری در سیستم‌های تولیدی بکار گرفته می‌شود. به عنوان مثال، یک متصدی در مرکز تماس ممکن است بخواهد یک مورد را به صورت حساب کارت اعتباری مشتریان اضافه کند. سپس آنها با استفاده از ۴ رقم آخر XXXX XXXX xxxx 6789، مرجع صورت‌حساب کارت را ذکر می‌کنند. یک متصدی فقط می‌تواند ۴ رقم آخر از شماره کارت را مشاهده کند، اما به محض اینکه سیستم صدور صورت‌حساب، جزئیات مشتری را برای شارژ کردن منتقل می‌کند، شماره کامل برای سیستم‌های درگاه پرداخت آشکار می‌شود.

این سیستم برای سیستم‌های آزمایشی بسیار مؤثر نیست اما برای سناریو صورت‌حساب که در بالا توضیح داده شد، بسیار مفید است. همچنین معمولاً به عنوان روش داده پوشانی پویا نیز شناخته می‌شود.[۱۱][۱۲]

قوانین پیچیده اضافی ویرایش

قوانین اضافی را می‌توان بدون توجه به نحوه ساخت روش‌های پوشش‌دهی، در هر راه‌حل پوشش‌دهی در نظر گرفت. مقالات آگونیستیک[۱۳] منبع خوبی از اطلاعات برای بررسی برخی ملزومات پیچیده متدوال برای راه‌حل‌های پوشش‌دهی تجاری است که شامل قوانین هم‌گام سازی ردیف داخلی، قوانین همگام سازی داخلی جدول و قوانین همگام سازی جدول[۱۴] به جدول می‌شود.

انواع مختلف ویرایش

داده پوشانی با ساخت داده‌های آزمایشی همراه است. دو نوع اصلی داده پوشانی عبارتند از داده پوشانی ایستا و حین انتقال.[۱۵]

داده پوشانی ایستا ویرایش

داده پوشانی ایستا معمولاً روی نسخه اصلی پایگاه داده اعمال می‌شود، اما می‌تواند برای مقادیر در منابع دیگر از جمله فایل‌ها نیز اعمال شود. در محیط‌های پایگاه داده، مدیران پایگاه داده تولیدی معمولاً پشتیبان‌های جدولی را در یک محیط مجزا بارگذاری می‌کنند، مجموعه‌داده را به زیرمجموعه‌ای که داده‌های لازم برای یک نوبت خاص از آزمایش را نگه می‌دارد، کاهش می‌دهند (تکنیکی با نام "زیرمجموعه یابی")، قوانین داده پوشانی را به داده‌ای که در حالت ایستا است اعمال می‌کنند، تغییرات کد ضروری را از کنترل منبع اعمال می‌کنند، یا داده را به محیط مورد نظر وارد می‌کنند.[۱۶]

داده پوشانی قطعی ویرایش

داده پوشانی قطعی، فرایند جایگزینی یک مقدار در یک ستون با مقدار مشابه در همان ردیف، همان جدول، همان پایگاه داده/طرح و بین نمونه‌ها/سرورها/پایگاه‌های‌داده‌است. به‌طور مثال: یک پایگاه داده چندین جدول دارد که هرکدام دارای ستونی با محتوای اسم‌های کوچک است. با پوشش‌دهی قطعی، اسم کوچک همیشه با همان مقدار مشابه جایگزین می‌شود - هر جا که ممکن است «لین» در پایگاه داده باشد - همیشه «لین» تبدیل به «دنیز» می‌شود.[۱۷]

مبهم سازی داده آماری ویرایش

همچنین گزینه‌های دیگری برای داده‌پوشانی ایستا وجود دارد که متکی به اختلالات تصادفی داده‌ها می‌باشند و برخی از ویژگی‌های آماری داده‌های اصلی را حفظ می‌کنند. روش Differential privacy[۱۸] و روش DataSifter[۱۹] از نمونه روش‌های مبهم سازی داده آماری می‌باشند.

داده پوشانی حین انتقال ویرایش

داده پوشانی حین انتقال (به انگلیسی: on-the-fly)[۲۰] در فرایند انتقال داده از محیطی به محیطی دیگر رخ می‌دهد، بدون اینکه تغییری در دیسکی که داده‌ها روی آن قرار گرفته‌اند، انجام شود. روش مشابهی به «داده پوشانی پویا» اعمال می‌شود اما یک سابقه در هر لحظه. این نوع از داده پوشانی برای محیط‌های توسعه پیوسته و همچنین برای نرم‌افزارهای کاملاً یکپارچه بسیار مفید است. سازمان‌هایی که از توسعه پیوسته یا شیوه‌های تحویل مداوم استفاده می‌کنند، زمان لازم برای ایجاد نسخه پشتیبان و بارگذاری آن در نسخه اصلی پایگاه داده را ندارند؛ بنابراین، ارسال مداوم زیرمجموعه‌های کوچکتر (دلتاها) داده‌های پوشش‌دهی آزمایشی تولیدی، از اهمیت زیادی برخوردار است. توسعه دهندگان در نرم‌افزارهای کاملاً یکپارچه از همان ابتدا فیدها را از سایر سیستم‌های تولیدی دریافت می‌کنند و پوشش‌دهی این فیدها یا نادیده گرفته می‌شود یا بودجه‌ای به آن تخصیص نمی‌یابد و این امر باعث می‌شود تا سازمان‌ها با یکدیگر منطبق نباشند. داده پوشانی حین انتقال در محل، امری ضروری می‌باشد.

داده پوشانی پویا ویرایش

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

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

داده پوشانی پویا مبتنی بر ویژگی و سیاست محور است. سیاست‌ها شامل موارد زیر می‌باشد:

  • پزشکان می‌توانند سوابق پزشکی بیمارانی که به آنها واگذار شده‌اند را مشاهده کنند. (فیلتر کردن داده‌ها)
  • پزشکان نمی‌توانند قسمت شماره تأمین اجتماعی را در یک پرونده پزشکی مشاهده کنند. (داده پوشانی)

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

در سالهای اخیر چندین استاندارد برای پیاده‌سازی فیلترسازی و پوشش‌دهی پویا پدیدار شده‌است. به عنوان مثال، سیاست‌های XACML می‌تواند برای داده‌پوشانی داخل پایگاه‌های داده مورد استفاده قرارگیرند.

پنج فناوری برای اعمال داده پوشانی پویا وجود دارد:

  1. در پایگاه داده: پایگاه داده SQL را می‌پذیرد و بازنویسی را برای مجموعه نتایج پوشش‌دهی برگشت یافته، اعمال می‌کند. برای توسعه دهندگان و مدیران پایگاه داده اما نه برای نرم‌افزارها قابل استفاده می‌باشد (زیرا مخازن اتصال (به انگلیسی: connection pools)، حافظه نهان نرم‌افزار و گذرگاه داده هویت کاربر نرم‌افزار را از پایگاه داده پنهان می‌کنند و همچنین می‌توانند خرابی داده را به وجود آورند).
  2. پروکسی شبکه بین نرم‌افزار و پایگاه داده: SQL را ذخیره می‌کند و بازنویسی را در درخواست انتخاب شده اعمال می‌کند. برای توسعه دهندگان و مدیران پایگاه داده با درخواست‌های ساده 'select' اما نه برای رویه‌های ذخیره شده (پروکسی‌ای که فقط 'exec' را شناسایی می‌کند) و نرم‌افزارها (زیرا مخازن اتصال، حافظه نهان نرم‌افزار و گذرگاه داده هویت کاربر نرم‌افزار را از پایگاه داده پنهان می‌کنند و همچنین می‌توانند خرابی داده را به وجود آورند) قابل استفاده می‌باشد.
  3. پروکسی شبکه بین کاربر نهایی و نرم‌افزار: شناسایی رشته‌های متن و جایگزینی آنها. این روش برای نرم‌افزارهای پیچیده قابل استفاده نیست زیرا هنگامی که جایگزینی رشته‌ای بی‌درنگ به صورت ناخواسته اعمال شود، به راحتی خرابی رخ می‌دهد.
  4. تغییرات کد نرم‌افزارها و XACML: تغییرات کد معمولاً دشوار است، حفظ آن غیرممکن است و برای نرم‌افزارهای با هم فشرده شده قابل استفاده نیست. برخی از نرم‌افزارها مانند Oracle E- Business Suite , PeopleSoft و JD Edvard این امکان را می‌دهند که یک رابط برنامه‌نویسی کاربردی را به کد نرم‌افزار خود برای فعال سازی داده پوشانی پویا اضافه کنند.[۲۱]
  5. در طول اجرا نرم‌افزار: با در نظر گرفتن زمان اجرا نرم‌افزار، سیاست‌هایی برای بازنویسی مجموعه نتایج حاصل از منابع داده تعریف می‌شوند، در حالی که برای نرم‌افزار کاربر کاملاً قابل مشاهده است. این روش تنها روش قابل استفاده برای پوشش‌دهی پویا نرم‌افزارهای پیچیده‌است زیرا کنترل درخواست داده، نتیجه داده و نتیجه کاربر را امکان‌پذیر می‌کند.
  6. پشتیبانی شده توسط افزونه مرورگر: در مورد SaaS یا نرم‌افزارهای وب محلی، افزونه‌های مرورگر می‌توانند برای پوشش‌دهی فیلدهای داده مربوط به انتخابگرهای CSS، پیکربندی شوند. این کار با نشانه‌گذاری فیلدهای حساس در نرم‌افزار انجام می‌شود، به عنوان مثال توسط یک کلاس HTML یا با پیدا کردن انتخابگرهای مناسب که فیلدهایی را برای مبهم‌سازی یا پوشش‌دهی مشخص می‌کنند.

داده پوشانی و فضای ابری ویرایش

در سالهای اخیر، سازمان‌ها بدون توجه به اینکه نرم‌افزارهای نهایی در فضای ابری میزبانی شوند یا درون‌سازمانی باشند، نرم‌افزارهای جدید خود را بیشتر در فضای ابری توسعه می‌دهند. در حال حاضر راه‌حل‌های فضای ابری به سازمان‌ها اجازه می‌دهند تا از زیرساخت به عنوان سرویس یا IaaS، بستر به عنوان سرویس یا PaaS و نرم‌افزار به عنوان سرویس یا SaaS استفاده کنند. حالت‌های مختلفی برای ایجاد داده‌های آزمایشی و انتقال آن‌ها از پایگاه‌های داده درون‌سازمانی به فضای ابری یا بین محیط‌های مختلف داخل فضای ابری وجود دارد. هنگامی که مشتریان به ارائه دهندگان فضای ابری برای مدیریت پایگاه‌های داده‌شان اعتماد می‌کنند و همچنین نیاز به محافظت از اطلاعات شخصی قابل‌شناسایی نیز دارند، داده پوشانی از اهمیت بالایی برخوردار می‌شود.[۲۲] داده پوشانی همواره بخشی از فرایندهای چرخه حیات توسعه سیستم‌ها می‌شود زیرا موافقت‌نامه‌های سطح خدمات محیط‌های توسعه صرف نظر از اینکه میزبانی در فضای ابری یا درون‌سازمانی باشد، معمولاً به اندازه موافقت‌نامه‌های سطح خدمات محیط‌های تولیدی سخت‌گیرانه نیستند.

منابع ویرایش

  1. "Data Masking vs. Data Encryption". www.iri.com. Innovative Routines International. Retrieved 24 August 2017.
  2. "Test data masking". DATPROF (به انگلیسی). 2014-05-20. Retrieved 2020-04-29.
  3. "Data Masking Definition". Retrieved 24 August 2017.
  4. "Information Management Specialists". GBT. Retrieved 24 August 2017.
  5. "Data Lifecycle and Test Management Methodology". Data Kitchen. Retrieved 24 August 2017.
  6. "Test Data Management: A Primer". IRI. Retrieved 24 August 2017.
  7. "Sub Setting". Data Kitchen. Retrieved 24 August 2017.
  8. "Database Subsetting". IRI. Retrieved 24 August 2017.
  9. "Data subsetting". DATPROF (به انگلیسی). 2019-05-23. Retrieved 2020-04-29.
  10. "Data processing systems with format-preserving encryption and decryption engines". Retrieved 24 August 2017.
  11. "IRI Dynamic Data Masking solutions". Retrieved 24 August 2017.
  12. "Dynamic Data Masking with IBM Optim". Retrieved 24 August 2017.
  13. "Data Masking: What You Need to Know" (PDF). Net2000 Ltd. Retrieved 24 August 2017.
  14. "Syncronisation and Complex Data Masking Rules Explained". Retrieved 24 August 2017.
  15. DataSunrise (2017). "Dynamic and Static data masking".
  16. "Static data masking functions". IRI. Retrieved 24 August 2017.
  17. "Deterministic data masking". DATPROF (به انگلیسی). 2020-03-19. Retrieved 2020-04-29.
  18. US 7698250, Cynthia Dwork & Frank McSherry, "Differential data privacy", published 2010-04-13, assigned to Microsoft Corp (original) and Microsoft Technology Licensing LLC (current) 
  19. Marino, Simeone; Zhou, Nina; Zhao, Yi; Zhou, Nina; Wu, Qiucheng; Dinov, Ivo (2018). "DataSifter: Statistical Obfuscation of Electronic Health Records and Other Sensitive Datasets". Journal of Statistical Computation and Simulation. 89 (2): 249–271. doi:10.1080/00949655.2018.1545228. PMC 6450541.
  20. "Eliminating Compliance Risks - Data Masking in the Cloud". Retrieved 24 August 2017.
  21. "Enterprise Application Security". MENTIS Inc. (به انگلیسی). Retrieved 2020-05-15.
  22. AWS Big Data (2019). "Protect and Audit PII data".