حفظ مجوزهای فایل و مالکیت در تبدیل‌های پلتفرمی

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


درک مدل‌های مجوز در پلتفرم‌های مختلف

مجوزهای POSIX در سیستم‌های یونیکس‑مانند حاکم هستند. هر فایل صاحب کاربری، صاحب گروهی و سه مجموعهٔ مجوز (خواندن، نوشتن، اجرا) برای کاربر، گروه و دیگران دارد. توزیعات مدرن لینوکس همچنین ACLهای POSIX را پشتیبانی می‌کنند که ورودی‌های دقیق‌تری فراتر از سه‌تایی کلاسیک امکان‌پذیر می‌سازند.

ACLهای ویندوز بیانگر توانایی بیشتری هستند. یک فهرست کنترل دسترسی (ACL) شامل دنباله‌ای از ورودی‌های کنترل دسترسی (ACE) است که قوانین اجازه یا رد برای کاربران، گروه‌ها یا هویت‌های داخلی مانند Authenticated Users را مشخص می‌کنند. هر ACE می‌تواند پرچم‌های ارث‌بری، مجوزهای خاص نوع شیء و تنظیمات حسابرسی را شامل شود.

هر دو پلتفرم ویژگی‌های گسترش‌یافته (xattrs) و شاخه‌های منبع (در macOS) را ارائه می‌دهند که متادیتای سفارشی را ذخیره می‌کنند — به‌عنوان مثال یک برچسب سفارشی «محرمانه» یا چکسام مورد استفاده یک سیستم خارجی. وقتی یک فایل صرفاً کپی می‌شود، اکثر سامانه‌های عامل این ویژگی‌ها را حفظ می‌کنند؛ اما اکثر ابزارهای تبدیل ساده، فایل را به‌عنوان یک جریان بایت نامشخص می‌پذیرند و همه چیز جز دادهٔ خام را حذف می‌کنند.


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

  1. رعایت مقررات — GDPR، HIPAA و سایر قوانین اغلب می‌خواهند کنترل‌های دسترسی پس از هر عملیات پردازش داده، نه فقط ذخیره‌سازی، حفظ شوند.
  2. پایداری عملیاتی — خطوط لوله خودکاری که به اجرای مبتنی بر گروه وابسته‌اند (مثلاً کار شبانه‌ای که فایل‌های صاحب data‑ingest را پردازش می‌کند) در صورت از دست رفتن مالکیت، شکست می‌خورند.
  3. کاهش ریسک — حذف ACLها می‌تواند یک سند خصوصی را به فایلی قابل خواندن برای همه تبدیل کند و سطح افشای داده را گسترش دهد.
  4. حسابرسی — برای اهداف قضایی یا e‑discovery وضعیت اولیهٔ مجوزها بخشی از زنجیرهٔ شواهد است؛ تغییر آن می‌تواند مسیر حسابرسی را باطل کند.

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


سناریوهای رایجی که در آن‌ها مجوزها ناپدید می‌شوند

1. ویندوز → لینوکس از طریق SMB یا FTP

وقتی فایلی از یک اشتراک ویندوز به سرور لینوکس بارگذاری می‌شود، معمولاً کلاینت SMB صاحب ویندوز را به یک کاربر محلی (اغلب nobody) نگاشته و ACL اصلی را دور می‌اندازد. FTP به‌عنوان یک پروتکل متنی ساده، تمام متادیتاها را حذف می‌کند.

2. سرویس‌های تبدیل مبتنی بر ابر

اکثر مبدل‌های SaaS یک درخواست multipart/form-data می‌پذیرند، محتویات فایل را می‌خوانند، تبدیل را انجام می‌دهند و نتیجه را برمی‌گردانند. سرویس payload را به عنوان بایت‌های خام می‌بیند؛ بنابراین بیت‌های سطح سیستم‌عامل هرگز از دستگاه کاربر خارج نمی‌شوند. پس از دانلود، فایل نتیجه‌ای مجوزهای پیش‌فرض دایرکتوری دریافت‌کننده را به ارث می‌برد. برای مثال، هنگام استفاده از convertise.app سند بارگذاری‌شده به‌طور کامل در ابر پردازش می‌شود و فایل بازگشتی با مجوزهای فولدر دانلود محلی می‌آید.

3. استخراج آرشیو بدون حفظ متادیتا

یک روش رایج این است که یک دایرکتوری را فشرده (zip) کنید، آرشیو را بفرستید، فایل‌های داخلش را تبدیل کنید و سپس نتایج را unzip کنید. فرمت zip می‌تواند مجوزهای یونیکس را ذخیره کند، اما بسیاری از برنامه‌های unzip پرچم -X را فعال نکرده و بیت‌ها را از دست می‌دهند؛ ابزارهای ZIP ویندوز نیز به‌طور کامل آن‌ها را نادیده می‌گیرند.


استراتژی‌های حفظ مجوزها در حین تبدیل

a. بستن فایل‌ها در آرشیوی که متادیتا را نگه می‌دارد

ساده‌ترین روش این است که فایل‌های مبدأ را در آرشیویی که صریحاً داده‌های مجوز را ضبط می‌کند، بگذارید و در صورت امکان خود آرشیو را تبدیل کنید. فرمت‌هایی که این قابلیت را دارند شامل:

  • tar با پرچم --preserve-permissions (-p). tar UID/GID، بیت‌های حالت و ACLهای POSIX را وقتی گزینه --acls فعال باشد (GNU tar) ذخیره می‌کند.
  • pax که یک آرشیو استاندارد POSIX است و می‌تواند ویژگی‌های گسترش‌یافته را ذخیره کند.
  • 7‑zip (.7z) که می‌تواند ACLهای ویندوز را هنگام استفاده از سوئیچ -sacl ثبت کند.

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

b. صادر و وارد کردن متادیتای مجوز به‌صورت جداگانه

وقتی قالب هدف نمی‌تواند بیت‌های مجوز را در خود داشته باشد (مثلاً تبدیل DOCX به PDF)، پیش از تبدیل توصیف‌گرهای امنیتی را به یک فایل جانبی خروجی بگیرید:

# Export POSIX ACLs to a JSON file
auditctl -a always,exit -F arch=b64 -S chmod,chown -k perm_export
getfacl -R /data/incoming > perms.acl

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

c. استفاده از ابزارهای تبدیل که متادیتا را رعایت می‌کنند

برخی ابزارهای خط فرمان گزینه‌های داخلی برای کپی‌کردن مجوزها دارند:

  • pandoc (برای قالب‌های سند) پرچم --preserve را برای حفظ بیت‌های حالت دارد.
  • ffmpeg می‌تواند پرچم metadata را کپی کند؛ اگرچه مجوزهای UNIX را انتقال نمی‌دهد، می‌توانید با -map_metadata تگ‌های جاسازی‌شده را حفظ کنید.
  • برای تبدیل تصویر، convert در ImageMagick گزینه -strip دارد (که متادیتا را حذف می‌کند) اما به‌طور پیش‌فرض حالت فایل را تغییر نمی‌دهد. از -strip اجتناب کنید و با -set filename:original می‌توانید بعداً مجوزها را بازگردانید.

d. اعمال مجدد برنامه‌ای با زبان‌های اسکریپتی

زبان‌هایی مانند Python توابع os.chmod, os.chown و os.setxattr را فراهم می‌کنند. یک روتین عمومی می‌تواند به صورت زیر باشد:

import json, os, pwd, grp

with open('perms.json') as f:
    perms = json.load(f)

for rel_path, meta in perms.items():
    dst = os.path.join('converted', rel_path)
    os.chmod(dst, meta['mode'])
    uid = pwd.getpwnam(meta['owner']).pw_uid
    gid = grp.getgrnam(meta['group']).gr_gid
    os.chown(dst, uid, gid)
    for attr, value in meta.get('xattrs', {}).items():
        os.setxattr(dst, attr, value.encode())

ذخیرهٔ متادیتا در قالب JSON قابل حمل به این معنی است که همان اسکریپت در ویندوز (از طریق pywin32 برای ACLها) و لینوکس کار می‌کند.


مثال یک گردش‌کار انتها‑به‑انتها

  1. فایل‌های منبع را در /project/source جمع‌آوری کنید.
  2. مجوزها را به perms.json صادر کنید با استفاده از یک ابزار Go کوچکی که درخت دایرکتوری را می‌چرخاند و UID/GID، حالت و رشته‌های SDDL ACL ویندوز را می‌نویسد.
  3. یک tarball ایجاد کنید: tar -cvpf source.tar /project/source — پرچم -p باعث می‌شود آرشیو دقیق بیت‌های حالت را ذخیره کند.
  4. tarball را به سرویس تبدیل بارگذاری کنید (مثلاً curl -F file=@source.tar https://api.convertise.app/convert?to=zip). سرویس یک آرشیو جدید converted.zip برمی‌گرداند که هر سندی تبدیل شده اما بسته‌بندی اصلی حفظ شده است.
  5. آرشیو را در میزبان مقصد استخراج کنید با tar -xvpzf converted.zip (یا 7z x در ویندوز با -sacl).
  6. ACLها را با دادن perms.json به اسکریپت پایتون بالا بازگردانید.

نتیجه مجموعه‌ای از فایل‌های تبدیل‌شده است که از نظر امنیتی دقیقاً مشابه اصل هستند.


آزمون و اعتبارسنجی

پس از یک اجرای تبدیل، مطمئن شوید که مجوزها با انتظارات مطابقت دارند:

  • مقایسه چکسام — برای هر فایل قبل و بعد از تبدیل SHA‑256 محاسبه کنید تا یکپارچگی محتوا تأیید شود؛ سپس هش‌های مجوزها را با استفاده از getfacl -c (لیناکس) یا icacls (ویندوز) به‌دست آورده و رشته‌های خروجی را هش کنید.
  • رجیسیون خودکار — گام‌ای را در یک خط لوله CI اضافه کنید که یک دایرکتوری نمونه را کپی می‌کند، تبدیل را اجرا می‌کند و بررسی می‌کند که خروجی stat -c "%a %U %G" با مبنای قبلی همسان است.
  • لاگ‌های حسابرسی — اگر سازمان شما نیاز به ردپای حسابرسی دارد، زمان‌های خروجی/وارد کردن مجوزها را همراه با شناسه‌های تبدیل ثبت کنید. این کار اکثر چارچوب‌های انطباقی را که ردیابی متادیتای امنیتی را می‌طلبند، برآورده می‌سازد.

موارد لبه‌ای و ملاحظات ویژه

فایل‌های رمزشده

وقتی فایلی در سطح فایل‌سیستم رمزشده است (مثلاً BitLocker ویندوز یا eCryptfs لینوکس)، سرویس تبدیل نمی‌تواند مجوزهای زیرین را ببیند چون داده‌ها به‌صورت بایت‌های رمز‌گذاری‌شده ارائه می‌شوند. روش پیشنهادی این است که به‌صورت امن در یک ناحیه استیجینگ رمزگشایی کنید، تبدیل را با حفظ ACLها انجام دهید و سپس نتیجه را دوباره رمزنگاری کنید.

تبدیل‌های استریمینگ

برخی خطوط لوله مستقیماً فایل را به یک بایناری تبدیل می‌فرستند (ffmpeg -i - -f mp4 -). در این موارد فایل اصلی پس از شروع استریم دیگر روی دیسک وجود ندارد و بیت‌های مجوز آن قابل کپی نیستند. راه‌حل این است که دسکتور فایل را تکثیر کنید: منبع را باز کنید، با fstat حالت آن را ذخیره کنید و پس از تکمیل تبدیل، خروجی را به حالت ذخیره‌شده chmod کنید.

نرمال‌سازی مسیرهای میان‌پلتفرمی

ویندوز از بک‌اسلش استفاده می‌کند و مسیرها را به‌صورت حساس به حروف کوچک/بزرگ نیست؛ در حالی که یونیکس حساس است. هنگام مطابقت متادیتای جانبی با فایل‌های تبدیل‌شده، مسیرها را با os.path.normcase (ویندوز) یا os.path.realpath (POSIX) قبل از جستجو نرمال کنید.


فهرست بررسی برای تبدیل ایمن از نظر مجوزها

  • مدل مجوز مبدأ را شناسایی کنید (POSIX، ACL ویندوز، xattr macOS).
  • متادیتای مجوز را قبل از تبدیل به یک نمایندهٔ قابل حمل صادر کنید.
  • اگر لازم است فایل‌ها را باندل کنید، فرمت آرشیوی را انتخاب کنید که این بیت‌ها را ذخیره می‌کند.
  • ابزارهای تبدیل را ترجیحاً انتخاب کنید که حالت فایل را حفظ می‌کنند مگر اینکه عمداً متادیتا را حذف کنید.
  • پس از تبدیل، مجوزها را با اسکریپت‌های خودکار بازگردانید.
  • با تست‌های مبتنی بر چکسام تأیید کنید که هم محتوا و هم ACLها مطابق انتظار هستند.
  • فرآیند را در یک run‑book داخلی برای حسابرسان مستند کنید.

نتیجه‌گیری

معمولاً تبدیل فایل به سؤال «آیا فایل جدید همان‌طور به نظر می‌رسد؟» کاهش می‌یابد. برای محیط‌های امن و منطبق، پاسخ باید شامل «آیا فایل جدید همان کنترل‌های دسترسی را حفظ می‌کند؟» باشد. با رفتار با مجوزها به عنوان دادهٔ صریح — استخراج، حمل همراه با بار، و بازگرداندن آن‌ها پس از تبدیل — می‌توانید خطوط لوله‌ای بسازید که هم وفاداری محتوا و هم وضعیت امنیتی را تضمین می‌کند. چه در حال انتقال PDFها از یک دسکتاپ ویندوز به یک سیستم بایگانی مبتنی بر لینوکس باشید، یا از مبدل ابری مانند convertise.app استفاده کنید، این شیوه‌ها نتایج پیش‌بینی‌پذیر و قابل حسابرسی فراهم می‌کنند بدون اینکه از راحتی سرویس‌های مدرن تبدیل فایل صرف‌نظر کنید.