از طریق منوی جستجو مطلب مورد نظر خود در وبلاگ را به سرعت پیدا کنید
سرفصلهای مطلب
زمانی که لاگ اطلاعات را تهیه میکنید ، باید مسئول انتشار اطلاعات خصوصی قابل شناسایی ( PII ) کاربران خود باشید ، در ادامه 5 راه حل و بهترین سناریو برای لاگ گیری موافق با شرایط GDPR را خواهید خواند .
تعریف کلی اطلاعات شخصی در GDPR نیازمند توحه ویژه به اطلاعات لاگ شده می باشد ، GDPR و اطلاعات شخصی در لاگ وب سرور یکی از مباحث محبوب در تالارهای گفتگو است ، به عنوان مثال آدرس ای پی و کوکیی هایی که ممکن است به عنوان اطلاعات شخصی تلقنی شوند در نتیحه چنین اطلاعاتی باید با موافقت کاربر برای مدت زمان کوتاهی ذخیره شود ، اکیدا توصیه می شود که اطلاعات شخصی کاربران قبل از اینکه در نرم افزارهای لاگ ذخیره شده و یا در اختیار اشخاص ثالث قرار گیرد بصورت ناشانس در آورده شود . این مطلب در دانشنامه گوگل آنالیستیکس یک نمونه خود از متد ناشناس سازی اطلاعات کاربر است .
توجه داشته باشید ارائه کنندگان سرویسهای ابری و SaaS نمیتوااند مسئولیت کامل اطلاعاتی که شما به آنها برای نگهداری و یا تحلیل و بررسی ارسال میکنید را بر عهده بگیرند ، سرویس دهنده معمولا دو نوع نقش دارد ، تامین کننده عموما به عنوان “کنترل کننده داده ” برای اطلاعاا شخصی شما ( نام ، آدرس ایمیل ، تلفن ، آدرس و غیره ) می باشد . برای محتوای شما از جمله لاگ ها می باشد ، برای محتوا شما مانند
خوب ، بهترین سناریو های پیروز شدن در نبرد سختگیرانه GDPR چیست ؟
1. ذخیره متمرکز لاگها (Centralize Log Storage)
محل خذیره لاگهای خود را متمرکز کنید ، این اکر به شما امکان اعمال قوانین در یک محل را خواهد داد ، متمرکز ساختن لاگ ها پیچیدگی و ریسک نگهداری و اعمال قواعد در چند محل را کاهش می دهد ، بشتر سرویس های مدیریت لاگ ، از قواین Rentation به ازای منابع داده مختلف پیروی می کنند ، بنابراین باید یک بازه نگهداری و ابقا لاگ قابل قوبل به ازای هر منبع لاگ تعریف کنید .
2.لاگ های محلی را از سرورهای خود پاک کنید ( بصورت متناوب )
اطلاعات تکراری زمانی که میخواهدی قوائد را اعمال کنید می تواند مشکلات زیادی ایجاد کند ، بنابراین باید مطمئن شوید که لاگهایی که در یک محل واحد متمرکز شده اند در اسرع وقت از سرورها پاک شوند ، Logrotate یک ابزار رایج برای پاک کردن لاگ ها بصورت دوره ای و مرتب ( هفتگی بصورت پیشفرض ) می باشد.همچنین مطمئن شوید که جریان ارسال لاگ ها به سرور مرکز نگهداری لاگ تقریبا بلادرنگ و در لحظه باشد.
3. ساختار لاگ های خود را مشخص کنید ،
شما می توانید لاگهای خود را بوسیله قواعد تجزیه کننده در سیستم تحویل لاگ خود نظام مند و دارای ساختار مشخص کنید ، لاگهای ساختارسافته ناشناس سازی اطلاعات حساس را همانطور که در گام بعدی اشاره شده است راحت تر می کند ، هر زمان ممکن بود لاگ اپلیکیشن ها باید در یک فرمت ساختاریافته مانند JSON ذخیره شوند ، استفاده از گزارش ثبت وقایع دارای ساختار منسجم زمان نفر ساعت مورد نیاز برای قوائد تجزیه و همچنین چرخه های پردازشی مورد نیاز را کاهش می دهد .
4. ناشناس سازی فیلدهای اطلاعاتی حساس در لاگ
شناسایی و = ناشناس کردن فیلدهای اطلاعات حساس باید قبل از ارسال به محل ذخیره متمرکز ( ریموت ) صورت پذیرد ، تکنیکهای چند گانه ای مانند Hashing , رمزنگاری و حذف اطلاعات حساس در فیلدها برای این کار میتواند مورد استفاده قرار گیرد.
5. لاگها را در انتقال رمزنگاری کنید.
فقط از کانال های رمزنگاری شده برای ارسال لاگ ها به محل ذخیره مرکزی استفاده کنید ، گزارشات وقایع معمولا بصورت غیر رمزنگاری شده از طریق Ssyslo روی پروتوکل UDP به دلیل اقزایش کارایی ارسال می شود . این اصلا خوب نیست ، این کار را انجام ندهید ، سیس لاگ خود را برای پشتیبانی از TLS پیکربندی کنید .
گام های بعدی برای تطبیق با GDPR چیست ؟
برخی از موارد بالا سماریو های عمومی ذخیره گزرشات (Logging) بودند که حتما باید دنبال می شدند . با تائید شدن نهایی GDPR پیروی از آنها برای محافظت از سازمان خود در مقابل مشکلات قانونی ضروری است . اگر شما اطلاعات اروپاییها را در سرورهایی خارح از اروپا ذخیره می کنید ، معنی آن این است که بطور موثر PII را صادر می کنید .(PII=Personally Identifiable Information) . قوانین اتحادیه اروپا اجازه صادرات و نگهداری اطلاعات کاربران اروپایی را نمی دهد مگر اینکه شرکتها بتوانند نشان دهند می توانند از اطلاعات و حریم خصوصی کاربران حفاظت کنند ، اگر شما لاگ های خد را به یک سرویس مدیریت لاگ در اروپا ارسال می کیتدبا ما تماس بگیرید تا با راه اندازی سرورهای متمرکز ذخیره لاگ و اعملا قوانین تفکیک و ناشتاس سازی اطلاعات شما را از مشکلات قانونی که ممکن است گیبانگیر شما شود حفاظت کنیم
مبع : DZONE
