وضعیت شواهد: تا تاریخ بررسی این نسخه، در صفحات عمومی جست‌وجوشده رهگارد سندی پیدا نشد که مدت دقیق نگهداری داده موقعیت، فهرست کامل دادههای جمع‌آوری‌شده، نقش‌های داخلی دسترسی، زیربخش‌های پردازش، روش حذف/خروجی، جزئیات رمزنگاری یا نتیجه آزمون امنیت را به‌طور جامع و قابل راستی‌آزمایی اعلام کند. بنابراین این صفحه نباید «گزارش شفافیت تکمیل‌شده» یا تضمین امنیت تلقی شود.
پاسخ کوتاه: امنیت داده ردیاب با جمله‌هایی مانند «سرور امن است» یا «اطلاعات محرمانه می‌ماند» قابل سنجش نیست. گزارش معتبر باید بگوید چه داده‌ای، برای چه هدفی، در کجا، تا چه مدت، با دسترسی چه نقش‌هایی و از چه مسیر حذف یا خروجی پردازش می‌شود؛ سپس کنترلهای فنی را با مدرک آزمون، دامنه و تاریخ مشخص کند.
شفافیت را از ادعای امنیت جدا کنید
| ادعای مبهم | شاهد لازم |
|---|---|
| داده‌ها امناند | دامنه کنترل، روش ارزیابی، تاریخ و نتیجه قابل استناد |
| اطلاعات محرمانه است | نقش‌های دسترسی، ثبت دسترسی و فرایند بازبینی |
| رمزنگاری داریم | لایه انتقال/ذخیره، مدیریت کلید و دامنه پوشش |
| اطلاعات حذف می‌شود | محرک حذف، مهلت، Backup و روش تأیید |
| داده با کسی به اشتراک نمی‌رود | فهرست پردازشگران، هدف، کشور/محل و قرارداد |
| دسترسی کنترل شده است | نقشها، حداقل دسترسی، MFA و تاریخچه تغییرات |
شفافیت یعنی خواننده بتواند مرز دانسته و نادانسته را ببیند. امنیت یک ویژگی صفر و یک نیست؛ به تهدید، معماری، عملیات، کاربران و زمان وابسته است. نبود گزارش عمومی نیز بهتنهایی اثبات ناامن‌بودن سامانه نیست، اما اجازه ادعای اطمینان‌بخش بدون مدرک را نمیدهد.
چه داده‌هایی باید در موجودی شفافیت نام برده شوند؟
یک سرویس ردیابی ممکن است با چند دسته داده روبه‌رو شود؛ وجود دقیق هر مورد در رهگارد باید از سند رسمی یا بررسی فنی تأیید شود. موجودی حداقلی باید وضعیت هر دسته را روشن کند:
- موقعیت جاری، تاریخچه مسیر، توقف، سرعت و زمان؛
- رویدادها و هشدارها مانند روشن‌شدن، ژئوفنس یا قطع برق؛
- شناسه دستگاه، خودرو، سیم‌کارت و نسخه Firmware؛
- حساب کاربر، شماره تماس، نقش و سازمان مرتبط؛
- فرمان‌ها، تغییر تنظیمات و تاریخچه مدیریتی؛
- Logهای فنی، IP، شناسه نشست، Crash و داده پشتیبانی؛
- فایل‌های خروجی، اسکرین‌شات‌ها و پیوست‌های ارسالی به پشتیبانی.
برای هر دسته باید منبع، هدف، الزام یا مبنای پردازش، گیرنده، مدت نگهداری و روش حذف جدا نوشته شود. عبارت کلی «اطلاعات کاربر» برای داده‌ای که مسیر روزانه و الگوی توقف را آشکار میکند کافی نیست.
چرخه عمر داده از جمع‌آوری تا حذف است
چارچوب حریم خصوصی NIST مدیریت ریسک حریم خصوصی را در سطح سازمانی می‌بیند و بر شناخت پردازش، حاکمیت، کنترل و ارتباط شفاف تأکید دارد. این چارچوب قانون ایران یا گواهی انطباق رهگارد نیست؛ زبان مشترکی برای مشخص‌کردن پرسش‌هاست.
- جمع‌آوری: داده از ردیاب، اپ، مرورگر یا پشتیبانی می‌آید؟
- انتقال: کدام مسیر و کدام واسطه آن را جابه‌جا میکند؟
- استفاده: نمایش، هشدار، گزارش، پشتیبانی یا تحلیل چه هدفی دارد؟
- ذخیره: کدام سامانه و Backup نگه‌دارنده است؟
- دسترسی و اشتراک: چه نقش یا پیمانکاری به چه بخشی می‌رسد؟
- خروجی و انتقال: کاربر یا سازمان چه نسخه‌ای می‌تواند دریافت کند؟
- حذف: چه چیزی، چه وقت و با چه تأییدی حذف می‌شود؟
صفحه راهنمای استفاده از Privacy Framework نیز بر چرخه عمر داده، نقش سازمان در اکوسیستم پردازش و ارزیابی دوباره کنترل‌ها تأکید میکند. گزارش شفافیت باید با تغییر محصول و پردازشگران به‌روزرسانی شود.
Retention باید برای هر نوع داده عدد و محرک داشته باشد
«تا زمانی که لازم باشد» پاسخ عملی نیست. مدت تاریخچه مسیر می‌تواند با Log امنیتی، Backup، فایل Export یا تیکت پشتیبانی فرق داشته باشد. گزارش باید برای هر دسته این موارد را روشن کند: مدت فعال، مدت Backup، محرک حذف، استثناهای فنی/قراردادی و زمان اعمال درخواست.
در منابع عمومی بررسیشده، عدد قابل اتکایی برای Retention همه این دسته‌ها پیدا نشد. بنابراین این مقاله هیچ روز یا ماهی را به رهگارد نسبت نمیدهد. کاربر یا مدیر ناوگان باید مقدار جاری را از قرارداد، تنظیمات حساب یا پاسخ رسمی و تاریخدار دریافت کند.
دسترسی باید به نقش و هدف محدود شود
نام کاربری مشترک بین راننده، مدیر، نصاب و پشتیبان مرز مسئولیت را از بین می‌برد. گزارش مناسب باید نقشها، سطح مشاهده، امکان فرمان، Export، تغییر دستگاه و مشاهده Log را تفکیک کند. راهنمای مستقل نقشها و سطح دسترسی ناوگان هنوز در صف تحریریه است؛ بنابراین این نسخه به صفحه منتشرنشده لینک نمیدهد.
برای هر دسترسی حساس باید علت، زمان و هویت نقش ثبت شود و دسترسی‌های قدیمی بازبینی شوند. این‌ها معیارهای مطلوب‌اند؛ وجود Audit Log یا سازوکار مشخص در رهگارد بدون مدرک رسمی ادعا نمی‌شود. در خروج کارمند، فروش خودرو یا تغییر پیمانکار، لغو دسترسی باید بخشی از فرایند باشد.
امنیت حساب و SIM دو لایه جدا هستند
رمز ضعیف، اشتراک حساب، نشست باز روی گوشی قدیمی و بازیابی ناامن میتوانند کنترلهای سرور را دور بزنند. صفحه امنیت حساب اپلیکیشن ردیاب مالک رمز، MFA در صورت پشتیبانی، نشست و دستگاه‌های مجاز است. این صفحه درباره وجود قابلیت خاص در نسخه فعلی رهگارد پیش‌داوری نمیکند.
سیم‌کارت و فرمان SMS سطح حمله دیگری دارند؛ صفحه امنیت سیم‌کارت ردیاب شماره مدیر، PIN و تعویض SIM را پوشش میدهد. امنیت اپ، سرور و سیم‌کارت را با یک برچسب کلی جمع نکنید.
رمزنگاری را فقط با دامنه و آزمون معنا کنید
عبارت «رمزنگاری‌شده» باید پاسخ دهد کدام داده، در کدام مسیر، بین کدام نقاط، با چه مدیریت کلیدی و در چه نسخه‌ای پوشش دارد. TLS برای یک API بهتنهایی درباره داده داخل ردیاب، Backup، Log یا فایل Export چیزی ثابت نمیکند. همچنین Hash رمز با رمزنگاری داده موقعیت یک مفهوم نیست.
استاندارد OWASP MASVS حوزه‌های Storage، Cryptography، Authentication، Network و Platform را جدا ارزیابی میکند. شرح رسمی MASVS نیز آن را چارچوب کنترل و آزمون اپ موبایل معرفی میکند، نه مهر تأیید خودکار برای یک اپ خاص.
در منابع عمومی بررسیشده، گزارش آزمون مستقلی با دامنه، نسخه، تاریخ و نتیجه برای اپ رهگارد پیدا نشد. پس ادعای «مطابق MASVS»، «تست نفوذشده» یا «رمزنگاری سرتاسری» در این نسخه حذف شده است.
ذخیره محلی گوشی و فایل Export فراموش نشوند
حتی اگر سرور کنترلهای مناسبی داشته باشد، Cache، Screenshot، اعلان، Clipboard، Backup گوشی و فایل‌های دانلودشده میتوانند داده حساس را بیرون از سامانه نگه دارند. راهنمای OWASP درباره Data Storage موبایل بر شناسایی و کاهش داده حساس محلی تأکید میکند.
فایل تاریخچه پس از دانلود، تحت کنترل گیرنده قرار می‌گیرد. صفحه خروجی تاریخچه مسیر مالک فرمت و تحویل فایل است. فایل را در پیام‌رسان عمومی، ایمیل گروهی یا پوشه مشترک بدون کنترل دسترسی قرار ندهید و پس از پایان نیاز، نسخه‌های اضافی را مدیریت کنید.
اشتراک با پردازشگران باید نام‌گذاری و محدود شود
سرویس ابری، نقشه، پیامک، Push، Crash reporting، پشتیبانی یا پرداخت ممکن است در اکوسیستم داده نقش داشته باشند؛ استفاده دقیق رهگارد از هرکدام باید مستند شود. گزارش شفافیت باید نام یا دسته پردازشگر، هدف، نوع داده، محل پردازش و سازوکار تغییر فهرست را اعلام کند.
عبارت «طرف ثالث مورد اعتماد» بدون دامنه کافی نیست. از سوی دیگر، وجود یک کتابخانه در اپ بهتنهایی ثابت نمیکند همه دادههای موقعیت برای سازنده آن ارسال می‌شود؛ این ادعا به تحلیل فنی و سند جریان داده نیاز دارد.
خروجی، اصلاح و حذف باید قابل پیگیری باشند
کاربر باید بداند چگونه نسخه‌ای از داده خود بگیرد، خطای حساب یا خودرو را اصلاح کند و حذف حساب/داده را درخواست دهد. در بررسی فعلی، صفحه عمومی مستقلی برای فرایند حذف حساب و داده پیدا نشد؛ بنابراین این مقاله وجود گزینه، مسیر یا مهلت مشخصی را بدون بررسی رابط و قرارداد ادعا نمیکند.
حذف حساب، حذف دستگاه از پنل و حذف همه نسخه‌های Backup لزوماً یک عملیات نیستند. پاسخ رسمی باید دامنه، استثنا، مهلت و روش تأیید را توضیح دهد. در ناوگان، درخواست یک کاربر ممکن است با مالکیت سازمانی داده تداخل داشته باشد؛ این موضوع نیازمند قرارداد و مشاوره حقوقی متناسب است.
حریم خصوصی کارکنان فقط مسئله فنی نیست
ردیابی خودروی سازمانی می‌تواند زمان، مسیر و توقف کارکنان را نشان دهد. اعلان روشن هدف، محدوده زمان/خودرو، نقش‌های مشاهده‌کننده و دوره نگهداری بخشی از حاکمیت است. صفحه حریم خصوصی ردیابی خودرو سازمانی این موضوع را جدا پوشش میدهد.
این مقاله توصیه حقوقی نیست و درباره رضایت یا الزام قانونی خاص حکم نمیدهد. مدیر سازمان باید قرارداد، سیاست داخلی و قوانین جاری حوزه خود را با متخصص بررسی کند.
گزارش رخداد امنیتی چه چیزهایی باید بگوید؟
یک برنامه پاسخ‌گویی باید کانال گزارش آسیب‌پذیری، روش احراز گزارشگر، سطح‌بندی رخداد، حفظ شواهد، اطلاع‌رسانی به افراد متاثر و اقدام اصلاحی را مشخص کند. انتشار جزئیات بهرهبرداری پیش از رفع می‌تواند خطر ایجاد کند؛ اما سکوت کامل نیز اعتماد قابل سنجش نمی‌سازد.
در منابع عمومی بررسیشده، کانال اختصاصی گزارش آسیب‌پذیری، SLA پاسخ، تاریخچه رخداد یا گزارش ممیزی عمومی پیدا نشد. این موارد به‌عنوان شکاف سند ثبت میشوند، نه اثبات نبود فرایند داخلی.
چک‌لیست کاربر و مدیر ناوگان
- از پشتیبانی، نسخه تاریخدار سیاست داده و Retention را بخواهید؛
- کاربران، نقشها و دستگاه‌های قدیمی را بازبینی کنید؛
- حساب مشترک را به حسابهای فردی و حداقل دسترسی تبدیل کنید؛
- Exportها و اسکرین‌شات‌های مکانی را خارج از پوشه عمومی نگه دارید؛
- هنگام فروش خودرو یا خروج کارمند، انتقال مالکیت و لغو دسترسی را ثبت کنید؛
- برای درخواست حذف یا اصلاح، شماره پیگیری و دامنه پاسخ را نگه دارید؛
- رخداد مشکوک را بدون انتشار رمز، OTP، توکن یا مسیر خام گزارش کنید.
چه چیزی یک گزارش شفافیت واقعی را کامل میکند؟
نسخه بعدی این صفحه زمانی می‌تواند «گزارش رهگارد» نام بگیرد که سند رسمی و تاریخدار حداقل این موارد را ارائه کند: موجودی داده و هدف، Retention هر دسته، نقش‌های دسترسی، پردازشگران، محل و جریان داده، کنترلهای حساب، روش Export/حذف، Backup، کانال رخداد و نتایج ارزیابی مستقل با دامنه روشن.
تا آن زمان، مرز درست چنین است: معیارهای ارزیابی از NIST و OWASP قابل استنادند؛ اما وضعیت پیاده‌سازی رهگارد برای موارد اعلام‌نشده «تأییدنشده» است. این صداقت از افزودن عبارت‌های امنیتی بدون شاهد مفیدتر است.
جمع‌بندی؛ شفافیت با پاسخ‌های قابل بررسی ساخته می‌شود
داده ردیاب فقط نقطه روی نقشه نیست؛ تاریخچه، رویداد، حساب، دستگاه، فرمان، Log و فایل پشتیبانی نیز میتوانند حساس باشند. گزارش معتبر باید چرخه عمر هر دسته را از جمع‌آوری تا حذف نشان دهد و امنیت را با دامنه آزمون و تاریخ پیوند بزند.
این نسخه هیچ تضمین فنی یا حقوقی برای رهگارد صادر نمیکند. نتیجه فعلی یک چک‌لیست شفافیت و فهرست شکاف شواهد عمومی است. تکمیل آن به مستندات رسمی، پاسخ تاریخدار و ارزیابی فنی مستقل نیاز دارد.
هنوز دیدگاهی ثبت نشده. اولین نفر باشید!