نرم‌افزار اقامتگاه شماره‌ی تلفن و هویت مهمان، مبلغ رزروها و حساب شرکا را کنار هم نگه می‌دارد؛ پس امنیتش را باید با پنج سؤال سنجید: چه کسی چه چیزی را می‌بیند، هر تغییر ردپا دارد یا نه، اگر سرویس بخوابد چه می‌شود، داده را می‌شود بیرون برد، و داده‌ی هویتی تا کِی نگه داشته می‌شود. این مقاله این پنج سؤال را باز می‌کند و در پایان می‌گوید در شاه‌کلید طبق کد چه چیزهایی هست و چه چیزهایی را من نتوانستم تأیید کنم. برای میزبان تکی که خودش تنها کاربر است، فقط دو سؤال آخر و رمز عبور قوی مهم‌اند؛ برای تیم چندنفره، همه‌ی پنج‌تا.
دسترسی نقش‌محور و اصل حداقل دسترسی
دسترسی نقش‌محور (RBAC) یعنی به‌جای تعیین اجازه برای تک‌تک آدم‌ها، چند نقش تعریف می‌کنید (پذیرش، حسابدار، مدیر شعبه) و هر کاربر یک نقش می‌گیرد. اصل حداقل دسترسی می‌گوید هر نقش فقط همان کاری را بتواند بکند که برای انجام وظیفه‌اش لازم است. دلیلش دو چیز است: اشتباه رایج‌ترین ریسک است (پذیرشی که اشتباهاً رزرو را حذف می‌کند)، و حساب هرکس ممکن است به دست دیگری بیفتد.
نمونه‌ی ملموس برای یک اقامتگاه:
نقش | باید بتواند | لازم نیست بتواند |
|---|---|---|
پذیرش | ثبت و ویرایش رزرو، دیدن واحدها | دیدن سود و سهم شرکا، حذف رزرو، دیدن همه‌ی ساختمان‌ها |
حسابدار | ثبت هزینه و گزارش مالی | ثبت یا ویرایش رزرو |
سرایدار/نظافت | دانستن برنامه‌ی ورود و خروج | مبلغ، مشخصات کامل مهمان |
نقش دقیق برای تیم‌های چندشعبه و مراحل تنظیم در نقش‌ها و دسترسی چندشعبه آمده است. سؤال کلیدی هنگام ارزیابی هر نرم‌افزار: محدودیت در سرور اعمال می‌شود یا فقط دکمه پنهان می‌شود؟ اگر فقط در رابط کاربری پنهان باشد، هر کس آدرس مستقیم را بداند عبور می‌کند.
لاگ حسابرسی: چه کسی، کی، چه چیزی را عوض کرد
لاگ حسابرسی (audit log) سابقه‌ی تغییرات است. راهنمای OWASP برای ثبت رویداد امنیتی، ثبت مواردی مثل افزودن و حذف کاربر، تغییر سطح دسترسی، و رخدادهای نشست را توصیه می‌کند و همزمان می‌گوید رمز، توکن و شناسه‌ی نشست نباید در لاگ بیایند. یعنی لاگ باید برای «ردیابی» کافی باشد، نه یک انبار جدید از اطلاعات حساس.
یک لاگ مفید این‌ها را دارد: کاربر، زمان، نوع عملیات، موجودیت هدف، و مقدار قبل و بعد. چک‌لیست ارزیابی:
آیا فقط ثبت می‌کند یا مقدار قبلی/بعدی را هم نشان می‌دهد؟
آیا می‌شود بر اساس کاربر، تاریخ و نوع عملیات فیلتر کرد؟
آیا دسترسی دیدن لاگ جدا از دسترسی عمومی است؟ (لاگ خودش اطلاعات حساس دارد.)
آیا کاربر عادی می‌تواند آن را پاک کند؟
آپ‌تایم و معنای ۹۹٫۹٪
عدد آپ‌تایم را باید به ساعت تبدیل کرد. با محاسبه‌ی ساده: ۹۹٪ یعنی تا حدود ۸۷٫۶ ساعت (۳٫۶۵ شبانه‌روز) قطعی در سال، ۹۹٫۹٪ حدود ۸٫۷۶ ساعت در سال یا حدود ۴۴ دقیقه در ماه. سه سؤال مهم‌تر از خود عدد: اندازه‌گیری چطور و چه کسی؟ آیا تعمیر برنامه‌ریزی‌شده حساب می‌شود؟ و اگر پایین‌تر آمد، غرامتی هست یا فقط وعده است؟ برای اقامتگاه، قطعی در ساعت ورود مهمان گران‌تر از قطعی نیمه‌شب است؛ بنابراین حتی با ۹۹٫۹٪ یک برنامه‌ی دستی کم‌کاغذی (فهرست ورود امروز چاپ‌شده یا ذخیره‌شده) داشته باشید. ایده‌ی «ابزار قطع شد چه کنم» در راهنمای اتوماسیون هم آمده است. SLA دقیق هیچ‌یک از ارائه‌دهنده‌های ایرانی را من بررسی نکردم.
پشتیبان‌گیری و خروجی داده
دو چیز متفاوت‌اند: پشتیبان (آیا ارائه‌دهنده از داده‌ی شما نسخه‌ی جدا دارد و چه مدت؟) و خروجی (آیا شما می‌توانید همه‌ی رزروها و مهمان‌ها را به فایل بگیرید؟). اولی را فقط از ارائه‌دهنده می‌شود پرسید و مکتوب خواست؛ دومی را خودتان می‌توانید همین امروز امتحان کنید: یک خروجی بگیرید و ببینید کامل است (رزرو، پرداخت، مهمان) یا فقط یک نمای نمایش‌داده‌شده. اگر نرم‌افزاری خروجی کامل نمی‌دهد، هزینه‌ی تغییرش بعداً از اشتراک‌هایش بیشتر می‌شود.
داده‌ی هویتی مهمان: کم بگیرید، کوتاه نگه دارید
دو اصل مرجع در GDPR (ماده‌ی ۵) این است: حداقل‌سازی (فقط داده‌ای که برای هدف لازم است) و محدودیت نگه‌داری (فقط تا زمانی که هدف ایجاب می‌کند). تأمین امنیت هم جزو همان اصول است. چند منبع در حوزه‌ی هتل می‌گویند دیدن مدرک هویتی لزوماً دلیل نگه‌داشتن کپی کامل نیست. GDPR مدت ثابتی تعیین نمی‌کند؛ مدت را قانون هر کشور یا هدف شما مشخص می‌کند (مثلاً یک منبع از دوره‌ی قانونی سه‌ساله برای ثبت مهمان در اسپانیا یاد می‌کند). این‌ها مرجع اروپایی‌اند و قانون ایران نیستند.
درباره‌ی قانون ایران برای نگه‌داری داده‌ی مهمان در نرم‌افزار، منبع رسمی‌ای پیدا نکردم. رویه‌ی محتاطانه تا روشن‌شدن قانون:
فقط فیلدهای لازم را وارد کنید و مدرک را فقط وقتی نگه دارید که کاربرد روشن دارد؛ ثبت مهمان و کارت مهمان این تعادل را شرح داده است.
برای مهمانان قدیمی یک زمان بازبینی تعیین کنید و داده‌ای را که دلیلی برای نگه‌داشتنش نیست پاک کنید.
دسترسی به مدارک را به همان نقش‌هایی بدهید که واقعاً به آن نیاز دارند.
شاه‌کلید در این چارچوب
این موارد را در کد بررسی کردم:
نقش‌ها: مجوزها بر اساس منبع (کاربران، رزروها، واحدها، پرداخت‌ها، هزینه‌ها، گزارش‌ها، تنظیمات و غیره) و عملیات مشاهده/نوشتن تعریف می‌شوند و در سرور بررسی می‌شوند. نقش غیرفعال دسترسی را قطع می‌کند و مدیر کل همیشه همه‌چیز را می‌بیند. دسترسی بر اساس ساختمان نیز برای هر کاربر قابل محدودسازی است (جزئیات در مقاله‌ی نقش‌ها).
گزارش فعالیت: هر ورودی کاربر، نوع عملیات، موجودیت، برچسب هدف، تغییر فیلد به فیلد (مقدار قبل و بعد)، آی‌پی و مرورگر را نگه می‌دارد؛ فیلدهایی مثل رمز عبور از تفاضل حذف می‌شوند. فیلتر بر اساس کاربر، نقش، نوع عملیات و بازه‌ی تاریخ دارد و دیدنش به دسترسی جدای «گزارش فعالیت‌ها» نیاز دارد. مسیر حذف لاگ در کد پیدا نکردم. لاگ فقط جاهایی ثبت می‌شود که کد آن را صدا زده؛ پوشش را همه‌جا ادعا نمی‌کنم. بخش بدهی‌ها عمداً داده‌ی مالی در لاگ نمی‌گذارد.
نشست‌ها: هر ورود یک نشست است؛ کاربر نشست‌های خودش را می‌بیند و می‌تواند بقیه‌ی دستگاه‌ها را ببندد، و مدیر با دسترسی مناسب می‌تواند نشست‌های کاربر دیگر را ببندد. مدت پیش‌فرض اعتبار توکن ۷ روز است (قابل تنظیم). رمزها با bcrypt ذخیره می‌شوند.
لیست سیاه: شماره‌ی موبایل در شبکه‌ی مشترک به‌صورت هش و ماسک‌شده ذخیره می‌شود.
چیزهایی که تأیید نکردم و نباید فرض شوند: SLA آپ‌تایم، پشتیبان‌گیری خودکار و دوره‌ی نگه‌داری آن، رمزنگاری روی دیسک، و سیاست امحای خودکار داده‌ی مهمان. این‌ها را از تیم پشتیبانی مکتوب بپرسید.
سؤال‌های پرتکرار
آیا برای میزبان تکی هم نقش‌ها لازم است؟
اگر خودتان تنها کاربرید، نه. به‌محض اینکه پذیرش یا حسابدار اضافه شد، نقش جدا بسازید.
لاگ فعالیت دلیل حقوقی است؟
می‌تواند مدرک کمکی باشد، ولی ارزش قضایی‌اش را مرجع قضایی تعیین می‌کند. منبع رسمی‌ای که تکلیف آن را روشن کند پیدا نکردم.
رمز عبور چه شکلی باشد؟
طول و یکتایی بیشتر از پیچیدگی ظاهری مهم است؛ از رمز مشترک بین چند سرویس استفاده نکنید و پس از رفتن هر همکار، همان روز حسابش را غیرفعال کنید.
این مقاله بخشی از راهنمای اتوماسیون اقامتگاه است.
مطالب مرتبط
اتوماسیون اقامتگاه؛ ابزارها و مرز انسان — نقشه‌ی ابزارهای فناوری برای میزبان (PMS، کانال‌منیجر، پیام خودکار، قیمت‌گذاری، قفل و حسگر)، معیار تصمیم برای…
مدیریت چندبرندی و چندارزی اقامتگاه — چندبرندی، چندمستأجری و وایت‌لیبل چه فرقی دارند، کی لازم‌اند و کی زیادی، قیمت چندارزی چه پیچیدگی حسابداری دارد و در…
ورود غیرحضوری و قفل هوشمند اقامتگاه — مقایسه‌ی روش‌های تحویل کلید، ضعف‌های امنیتی مستند قفل‌های هوشمند، قاعده‌ی مدیریت کد، پروتکل خرابی باتری و اینترنت، و…
نظرها