Test Data Privacy: اکنون پیروی از مقررات جدید را آغاز کنید

نوشته های مرتبط

اتوماسیون تست بیش از حد

آبان ۲۴, ۱۴۰۰

نحوه بهینه سازی تجربه مشتری با استفاده از تست

آبان ۱۲, ۱۴۰۰

چگونه تعامل صحیح کسب و کاری می تواند به تحول “همیشه شاد” یا Happy Ever After منجر شود؟

آبان ۱۰, ۱۴۰۰

EU General Data Protection Regulation-GDPR به قوانین جدید مورد نیاز کمپانی‌ها به منظور پاکسازیِ تمام نمونه‌های اطلاعات شناسایی شخصیِ مشتریان اتحادیه اروپا(بنا به درخواست مشتری) اشاره دارد. علاوه بر این GDPR نیازمند رضایت صریح مشتری برای استفاده از داده‌های آنها برای اهداف مختلف، مشتمل بر تست اپلیکیشن است. این یعنی اگر سازمان از داده‌های مشخص و زندۀ مشتری در فرآیندهای تست خود استفاده میکند، در حال نقض GDPR هستند.

عدم تطابق با تمام جنبه‌های GDPR تا ۲۵ مِی سال ۲۰۱۸ منتج به جرایم بسیار سنگین خواهد شد، و این فقط کمپانی‌های اتحادیه اروپا نیستند که الزام به مراقبت دارند. هر کمپانی دیگری(شامل بسیار از شرکت‌های آمریکایی) که به مشتریان در بدنه اتحادیه اروپا خدمات داده و داده‌ها را پردازش می‌کند باید با این قاعده مطابقت داشته باشد.

ممکن است GDPR Deadline دور به نظر برسد، اما با توجه به دامنه تغییر، شرکت‌ها نیازمند ایجاد روشی خواهند شد که داده‌های حساس مشتری را اداره کنند، که البته آغاز آماده‌سازی آن خیلی نزدیک نیست. این تغییرات تمام روش‌های موجود در تیم‌های QA و تست نرمافزار که اغلب داده‌های شخصی، در دوره تست آنها را اداراه می‌کند، فرو خواهد ریخت.

حصول اطمینان از حفظ حریم خصوصیِ داده‌های مشتری که در تست مورد استفاده هستند، همواره یک مسئله مهم بوده است. بر اساس یک نظرسنجی که اخیرا از مدیران IT شرکت‌های بزرگ به عمل آمد، ۸۳% از سازمان‌های ایالات متحده در هنگام تست اپلیکیشن‌ها از داده‌های زنده مشتری در تست سیستم‌ها استفاده می‌کنند، چون بر این باورند که استفاده از داده‌های زنده متضمن یک تست قابل اطمینان و نشان دهنده دقت محیط تولید ایشان است. البته یک آمار ۸۳% دیگر هم وجود دارد، که نمایانگر شرکت‌هاییست که به طور منظم داده‌های مشتری را برای برونسپاران با اهداف تست آماده می‌کنند. این دستورالعملی برای فجایع بالقوه‌ایست که طی آن داده‌ها به صورت دستی و اشتباه ثبت شوند. GDPR عواقب را حتی وخیمتر می‌کند، آنچنانکه کمپانی‌های ناسازگار با جریمه‌ای برابر با ۴ درصد گردش مالی سالانه خود دردنیا مواجه می‌شوند.

اما در اینجا می‌خواهیم در مورد Test Data Privacy صحبت کنیم.

کلید Test Data Privacy، برآوردن نیازهای تسترها در زمینه‌های بهره‌وری، سرعت، و نمایش‌هایی دقیقتر از رفتار اپلیکیشن و داده‌ها در محیط بهره‌برداریست، که اختفا و حفاظت تسترها در برابر خطرات غیرعمدی را تضمین می‌کند. در اینجا نکاتی برای شروع به کار روی یک پروژه Test Data Privacy به منظور تطابق با General Data Protection Regulation (مقررات عمومیِ حفاظت از دادهها) اتحادیه اروپا وجود دارد

در حالی که همه سازمان‌ها باید به منظور کاهش ریسکِ رخنۀ امنیتی، روی تضمین Test Data Privacy متمرکز شوند، شرکت‌های آمریکایی نیاز دارند با GDPR تطابق یابند. ممکن است آغاز یک پروژه Test Data Privacy مانند یک وظیفه دلهره‌آور به نظر برسد، که البته نباید اینچنین باشد. در اینجا نکاتی برای آغاز این کار وجود دارد.

موجودی داده‌های حساس را بگیرید و چیزهایی را که می‌توان نگه داشت شناسایی کنید

اولین قدم، دریافت موجودی کلیۀ داده‌های حساس با ایجاد و شناسایی ستونهای اطلاعاتیست که باید تبدیل شده و تغییر قیافه دهند. بر خلاف باور عموم، این کار شامل نامها نمی‌شود؛ در حقیقت، زدودن نام‌ها می‌تواند آنرا برای شناسایی رکوردهای مشتریان بسیار سخت کند، چون داده در طول پلتفرم‌ها و مسیرهای تراکنشی در فرآیند تست حرکت می‌کند. برای مثال، در مدل عمومی رمزنگاری یا Encryption، یک ورودی از نامی مانند “مِلیک وارطانیان” ممکن است خروجیای به شکل “LR/TVdWcXtsdCFgN0zhLEw” به شما تحویل دهد. این برای تسترها غیرقابل تشخیص است، مگر اینکه فرآیند خودکار باشد، و باقی تست به صورت دستی ادامه یابد.

هدف از Test Data Privacy این نیست که خود داده را پنهان کنید، بلکه هدف این است که شناسایی هر کدام از داده‌ها را به صورت منطقی سخت کنید(مفهومی که با عنوان Pseudonymism شناخته می‌شود). استفاده از نام مشتریان واقعی از پایگاه داده محیط بهره‌برداری تا زمانیکه این نامها به آدرس محل سکونت شخص، تاریخ تولید وی، پارسپورت‌ها، یا دیگر اطلاعات شناسایی متصل نشود، خوب است. نگه داشتن نام‌های واقعی و قابل تشخیص، فرآیندهای تست را برای تسترهای دستی سریعتر، کارآمدتر، و دقیقتر می‌سازد، آنچنانکه آنها اجرای اپلیکیشن را در محیط تست Track می‌کنند.

روی قانون تغییر قیافه تصمیم بگیرید

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

چالش رمزنگاریِ استاندارد، موضوعیست که می‌تواند یک بار دیگر شناسایی اینکه چه نوع اطلاعاتی باید توسط اشخاص قابل رویت باشد، را برای تسترها بسیار سخت گرداند. مثالی که قبلا در مورد رمزنگاریِ نام “ملیک وارطانیان”، زده شده را در نظر بگیرید: ” LR/TVdWcXtsdCFgN0zhLEw”. نه تنها این اطلاعات برای رویت و فراخوانی به عنوان یک نام بسیار سخت هستند، بلکه هیچکس هم نمی‌تواند بگوید که این رشته مُبَیِن یک نام است، یا آدرس، یا یک شماره تلفن!

در زمینه Test Data Privacy، دیگر قوانین تغییر قیافه، که به عنوان رمزنگاریِ حفاظت از فرمت یا Format-Preserving Encryption شناخته می‌شوند، تمایل به انجام بهتر کارها دارند. Format-Preserving Encryption فرمت اصلی داده ورودی را در حالیکه آنرا ماسک کرده است، نگاه می‌دارد. بنابراین آنرا برای اهداف تست داده‌ها مفیدتر می‌سازد. یک مثال در این مورد شماره‌های تلفن در برتانیاست، که ممکن است با +۴۴ آغاز شوند(به گونه‌ای تستر می‌داند آن یک شماره تلفن است)، اما باقی داده‌ها رمزنگاری شده‌اند.

در حالیکه Format-Preserving Encryption قادر است برای داده‌هایی مانند شماره‌های تلفن، عالی کار کند، اما همیشه نمی‌تواند برای داده‌هایی که از یک استاندارد خاص در قالب خود پیروی می‌کنند خوب عمل کند؛ مانند آدرس. این امر با توجه به اینکه آدرس‌ها به صورتی متفاوت در کشورهای مختلف در سراسر اتحادیه اروپا قالب‌بندی می‌شوند، به صورت خاص برای سازمان‌هایی که به موضوع GDPR می‌پردازند صادق است. ترجمه داده‌ها، که از مقادیر ذخیره شده جاری در فایل‌ها به عنوان جایگزینی برای مقادیر دادهایِ حساس استفاده می‌کنند، گزینه‌ای خوب برای سازمان‌هاییست که در تلاش هستند تا اطلاعات آدرس‌هایی که از یک قالب واحد پیروی می‌کنند را ماسک کنند.

Lookup Tableها را ایجاد کنید

اگر باید نام‌ها و آدرس‌های واقعی مورد استفاده قرار گیرد، هیچ سحر و جادویی برای سادگی فرآیند وجود ندارد؛ بلکه باید Data Lookup Tableها راه‌اندازی شوند. با این حال، نیاز به یک فرآیند دشوار یا حساس به زمان وجود ندارد.

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

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

حفاظت از داده‌های مشتری را از هم اکنون آغاز کنید

کلید Test Data Privacy، ایجاد یک موازنه مهم است: برآوردن نیازهای تسترها برای بهره‌وری، سرعت و نمایش دقیقتری از داده‌ها و رفتار اپلیکیشن در محیط بهره‌برداری. البته با توجه به حصول اطمینان از حریم خصوصی و حفاظت کردن تسترها از مخاطرات غیرعمدی.

نیاز به Test Data Privacy چیز جدیدی نیست. الزامات اخیر مانند GDPR به سادگی آنرا مرتفع نموده است.