اکسس کنترل برای پروژه‌های سازمانی چیست؟
اکسس کنترل برای پروژه‌های سازمانی فقط به معنی نصب یک کارت‌خوان کنار آسانسور یا درب ورودی نیست.
در یک پروژه سازمانی، تعداد کاربران، ساختمان‌ها، آسانسورها، طبقات، ورودی‌ها و سناریوهای دسترسی می‌تواند بسیار بیشتر از یک ساختمان معمولی باشد. به همین دلیل سیستم کنترل تردد باید متناسب با ساختار سازمان، نقش کاربران، نقاط کنترل و سیاست‌های امنیتی مجموعه طراحی شود.
ممکن است یک پروژه سازمانی شامل موارد زیر باشد:
- یک ساختمان اداری با چند آسانسور
- چند ساختمان در یک مجموعه
- چند بلوک ساختمانی
- چند طبقه پارکینگ
- ورودی اصلی مجموعه
- ورودی‌های فرعی
- اتاق‌های حساس و محدود
- واحدهای اداری یا سازمانی مختلف
- کارکنان با سطح دسترسی متفاوت
- مدیران و مسئولان ارشد
- نیروهای خدماتی و پیمانکاران
- مهمانان و مراجعه‌کنندگان
- نگهبانی و حراست
در چنین پروژه‌ای، سؤال اصلی دیگر این نیست که «کدام اکسس کنترل را بخریم؟»
سؤال اصلی این است:
«چگونه یک معماری کنترل تردد طراحی کنیم که با ساختار واقعی سازمان هماهنگ باشد؟»
در راهکارهای سازمانی مدرن نیز معمولاً دسترسی کاربران بر اساس نقش، محل، زمان و سطح مجوز تعریف می‌شود و سیستم باید بتواند از یک سایت کوچک تا مجموعه‌های چندسایتی توسعه پیدا کند.
چرا اکسس کنترل سازمانی با اکسس کنترل یک ساختمان معمولی متفاوت است؟
در یک ساختمان کوچک ممکن است چند ده کاربر داشته باشیم و همه آنها تقریباً شرایط دسترسی مشابهی داشته باشند.
اما در یک مجموعه سازمانی ممکن است صدها یا هزاران کاربر وجود داشته باشند که هرکدام سطح دسترسی متفاوتی دارند.
برای مثال:
| گروه کاربری | آسانسور | طبقات | پارکینگ | ورودی‌های خاص |
| کارکنان عادی | مجاز | طبقات محل کار | مجاز | محدود |
| مدیران | مجاز | گسترده | مجاز | گسترده |
| حراست | مجاز | گسترده | مجاز | گسترده |
| خدمات | محدود | مشخص | محدود | مشخص |
| پیمانکار | محدود | مشخص | در صورت نیاز | زمان‌دار |
| مهمان | محدود | طبقه مقصد | در صورت نیاز | محدود |
بنابراین در پروژه سازمانی، هویت کاربر به تنهایی کافی نیست؛ سیستم باید بداند این کاربر چه نقشی دارد و به کدام بخش‌های مجموعه مجاز است.
اکسس کنترل سازمانی از کجا شروع می‌شود؟
یک اشتباه رایج این است که تصور کنیم پروژه سازمانی حتماً باید از ابتدا یک سامانه بسیار بزرگ و پیچیده باشد.
در واقع یک پروژه سازمانی می‌تواند از یک نقطه مشخص شروع شود.
برای مثال:
یک ساختمان → یک آسانسور → چند طبقه → کارت RFID
اگر نیاز مجموعه افزایش پیدا کند، معماری سیستم می‌تواند توسعه پیدا کند:
چند آسانسور → چند ساختمان → پارکینگ → ورودی‌ها → کاربران متعدد → گزارش‌گیری → اپلیکیشن → سامانه تحت وب
این نگاه مرحله‌ای اهمیت زیادی دارد؛ زیرا ممکن است سازمان امروز فقط به کنترل آسانسور نیاز داشته باشد، اما در آینده کنترل سایر نقاط نیز به پروژه اضافه شود.
بنابراین هنگام انتخاب سیستم، فقط امکانات فعلی را نباید دید.
باید پرسید:
آیا این راهکار قابلیت توسعه متناسب با آینده سازمان را دارد؟
کنترل تردد آسانسور در پروژه‌های سازمانی
آسانسور یکی از مهم‌ترین نقاط کنترل دسترسی در یک ساختمان سازمانی است.
اگر ورودی ساختمان با کارت کنترل شود اما پس از ورود، فرد بتواند بدون محدودیت هر طبقه‌ای را از داخل آسانسور انتخاب کند، کنترل ورودی به‌تنهایی نمی‌تواند دسترسی طبقات را مدیریت کند.
به همین دلیل در پروژه‌های سازمانی، کنترل دسترسی آسانسور می‌تواند به‌صورت سطح طبقه تعریف شود.
برای مثال:
کارمند واحد مالی → طبقات ۲ و ۳
کارمند فناوری اطلاعات → طبقات ۴ و ۵
مدیر ارشد → طبقات ۱ تا ۸
پیمانکار → فقط طبقه ۶ و فقط در ساعات مشخص
این مدل کنترل طبقه‌ای یکی از قابلیت‌های مهم سیستم‌های کنترل دسترسی آسانسور در پروژه‌های چندمستأجره و سازمانی است.
وقتی یک سازمان چند آسانسور دارد
در ساختمان‌های سازمانی بزرگ ممکن است چند آسانسور در کنار یکدیگر فعالیت کنند.
در این شرایط باید مشخص شود که:
- کدام کاربران از کدام آسانسورها استفاده می‌کنند؟
- آیا تمام آسانسورها دسترسی یکسان دارند؟
- آیا یک کارت باید روی چند آسانسور فعال باشد؟
- آیا برخی آسانسورها مخصوص کارکنان هستند؟
- آیا آسانسورهای خاصی برای مدیران یا بخش‌های امنیتی وجود دارند؟
- آیا دسترسی طبقات در تمام آسانسورها یکسان است؟
برای مثال ممکن است یک کاربر اجازه داشته باشد از سه آسانسور یک ساختمان استفاده کند، اما فقط طبقات ۲، ۳ و ۴ برای او مجاز باشد.
در مقابل، مدیر ساختمان ممکن است روی تمام آسانسورها و تمام طبقات دسترسی داشته باشد.
پس در پروژه‌های چندآسانسوره، تعداد آسانسورها بخشی از معماری سیستم کنترل تردد است، نه صرفاً تعداد کارت‌خوان‌ها.
اکسس کنترل برای مجموعه‌های چندساختمانی
پروژه سازمانی ممکن است به یک ساختمان محدود نباشد.
برای مثال یک سازمان ممکن است:
- ساختمان اداری مرکزی
- ساختمان مدیریت
- ساختمان پشتیبانی
- ساختمان خدمات
- مرکز آموزش
- پارکینگ مرکزی
- ساختمان‌های عملیاتی
داشته باشد.
در این حالت، مدیریت دسترسی باید بتواند بین ساختمان‌ها تفاوت قائل شود.
ممکن است یک کارمند فقط به ساختمان محل فعالیت خود دسترسی داشته باشد، در حالی که مدیر یا مسئول حراست به چند ساختمان مجاز باشد.
در سامانه‌های سازمانی مدرن، مدیریت چند سایت و تعریف سیاست‌های دسترسی برای ساختمان‌ها و مکان‌های مختلف یکی از ویژگی‌های مهم معماری Enterprise محسوب می‌شود.
یک کارت می‌تواند برای چند نقطه از سازمان استفاده شود؟
در معماری مناسب، می‌توان یک credential را برای یک کاربر تعریف کرد و سپس سطح دسترسی او را در نقاط مختلف مشخص کرد.
برای مثال:
کارت کارمند → ورودی اصلی + آسانسور ساختمان A + پارکینگ
اما همین کارت ممکن است برای ساختمان B مجوز نداشته باشد.
یا:
کارت مدیر → ورودی اصلی + ساختمان A + ساختمان B + پارکینگ + طبقات مدیریتی
این ساختار باعث می‌شود سازمان مجبور نباشد برای هر نقطه یک سیستم مستقل و جداگانه برای کاربران ایجاد کند.
کنترل دسترسی بر اساس نقش سازمانی
یکی از مهم‌ترین تفاوت‌های پروژه سازمانی، وجود گروه‌ها و نقش‌های مختلف است.
به جای اینکه برای تک‌تک افراد به‌صورت جداگانه مجوز تعریف شود، می‌توان ساختار دسترسی را بر اساس گروه طراحی کرد.
برای مثال:
گروه مدیریت
دسترسی گسترده به ساختمان‌ها و طبقات مدیریتی.
گروه کارکنان
دسترسی به ساختمان و طبقات محل فعالیت.
گروه حراست
دسترسی گسترده برای انجام وظایف امنیتی.
گروه خدمات
دسترسی محدود به بخش‌های موردنیاز.
گروه پیمانکار
دسترسی محدود و در صورت نیاز زمان‌دار.
گروه مهمان
دسترسی موقت و محدود.
این روش مدیریت را ساده‌تر می‌کند؛ زیرا با تغییر جایگاه یک کاربر، می‌توان گروه یا سطح دسترسی او را تغییر داد.
اکسس کنترل سازمانی و مدیریت زمان دسترسی
در پروژه‌های سازمانی فقط مکان اهمیت ندارد؛ زمان دسترسی نیز اهمیت دارد.
برای مثال:
کارمند عادی:
شنبه تا چهارشنبه — ساعات اداری
نیروی نگهبانی:
۲۴ ساعته
پیمانکار:
فقط دوشنبه — ساعت ۹ تا ۱۳
مهمان:
فقط در بازه زمانی مشخص
مدیر:
بدون محدودیت یا با محدودیت کمتر
در سیستم‌هایی که زمان‌بندی دسترسی را پشتیبانی می‌کنند، می‌توان مجوز را همزمان بر اساس کاربر، محل و زمان تعریف کرد. این مدل در راهکارهای سازمانی و کنترل آسانسور مدرن نیز مورد استفاده قرار می‌گیرد.
کنترل دسترسی مهمان در پروژه‌های سازمانی
مراجعه‌کنندگان یکی از مهم‌ترین گروه‌های کاربری در سازمان‌ها هستند.
مهمان ممکن است برای ملاقات با:
- مدیر
- واحد مالی
- واحد منابع انسانی
- واحد فنی
- واحد فروش
- واحد حقوقی
وارد سازمان شود.
اما این فرد نباید الزاماً به تمام ساختمان و طبقات دسترسی داشته باشد.
برای مثال:
مهمان → ورودی اصلی → طبقه ۵
پس از پایان مراجعه نیز دسترسی او باید پایان پیدا کند.
در سیستم‌های پیشرفته‌تر، می‌توان دسترسی مهمان را به‌صورت موقت یا زمان‌دار تعریف کرد و سوابق ورود و خروج را نیز در اختیار مدیریت قرار داد. راهکارهای Enterprise فعلی نیز visitor management را در کنار access control و audit trail قرار می‌دهند.
کنترل دسترسی پیمانکاران و نیروهای خدماتی
در بسیاری از سازمان‌ها، پیمانکاران و نیروهای خدماتی دائماً در حال رفت‌وآمد هستند.
برای مثال:
- شرکت تأسیسات
- شرکت نظافت
- پیمانکار آسانسور
- پیمانکار شبکه
- شرکت نگهداری دوربین
- تعمیرکار تجهیزات
- پیمانکار ساختمانی
این افراد معمولاً نباید همان سطح دسترسی کارکنان سازمان را داشته باشند.
می‌توان برای آنها یک سطح دسترسی محدود تعریف کرد.
مثلاً:
پیمانکار شبکه → اتاق سرور + طبقه ۳
یا:
تکنسین آسانسور → موتورخانه + محل‌های فنی موردنیاز
در راهکارهای Enterprise، مدیریت پیمانکار و دسترسی محدودمدت یکی از سناریوهای مهم کنترل دسترسی محسوب می‌شود.
وقتی کارمند سازمان تغییر سمت می‌دهد
در سازمان‌ها تغییرات نیروی انسانی دائمی است.
یک کارمند ممکن است:
- به واحد دیگری منتقل شود؛
- ارتقا پیدا کند؛
- مسئولیت جدید بگیرد؛
- از سازمان خارج شود؛
- مدتی مأمور شود؛
- به ساختمان دیگری منتقل شود.
اگر سیستم کنترل تردد به‌صورت اصولی طراحی شده باشد، تغییر سطح دسترسی کاربر نباید باعث تغییر تنظیمات سایر کاربران شود.
برای مثال:
کارمند مالی → انتقال به مدیریت
دسترسی او می‌تواند از:
طبقات ۲ و ۳
به:
طبقات ۲، ۳، ۷ و ۸
تغییر کند.
این همان جایی است که اهمیت مدیریت ساختاریافته کاربران و گروه‌های دسترسی مشخص می‌شود.
حذف یا غیرفعال کردن کارت کارمند
اگر کارت یک کارمند گم شود یا همکاری او با سازمان پایان پیدا کند، باید امکان غیرفعال کردن credential وجود داشته باشد.
این موضوع در یک سازمان بزرگ اهمیت بسیار بیشتری دارد؛ زیرا تعداد کارت‌ها و کاربران زیاد است.
در یک سیستم مناسب:
کاربر حذف یا غیرفعال می‌شود → دسترسی او قطع می‌شود → سایر کاربران بدون تغییر باقی می‌مانند.
در پروژه‌های بزرگ‌تر، حتی بهتر است سوابق تغییرات مدیریتی نیز قابل ثبت و پیگیری باشند.
اکسس کنترل سازمانی فقط کارت RFID نیست
کارت و تگ RFID یکی از روش‌های متداول شناسایی هستند، اما در یک پروژه سازمانی ممکن است روش‌های دیگری نیز موردنیاز باشد.
بسته به سطح امنیت و نوع پروژه می‌توان از روش‌هایی مانند:
استفاده کرد.
برای مثال ممکن است:
کارکنان → کارت
اتاق حساس → اثر انگشت
مهمان → دسترسی موقت
و در یک پروژه سفارشی، ترکیبی از چند روش شناسایی در کنار یکدیگر قرار گیرد.
بنابراین انتخاب روش شناسایی باید بر اساس سطح امنیت، تعداد کاربران، نوع کاربری و سناریوی واقعی سازمان انجام شود.
چرا در پروژه سازمانی گاهی یک اکسس کنترل آماده کافی نیست؟
محصول آماده زمانی بهترین انتخاب است که نیاز پروژه با امکانات آن مطابقت داشته باشد.
اما ممکن است سازمان نیازهایی داشته باشد که یک محصول استاندارد پاسخگوی آنها نباشد.
برای مثال:
- تعداد خروجی خاص
- چند روش شناسایی همزمان
- چند آسانسور
- چند ساختمان
- مدیریت پارکینگ
- اپلیکیشن اختصاصی
- سامانه تحت وب
- گزارش‌گیری خاص
- اتصال به سیستم‌های موجود
- پنل شستی اختصاصی
- ساختار دسترسی مخصوص سازمان
در این شرایط، موضوع از انتخاب محصول وارد حوزه طراحی راهکار می‌شود.
نوین کیا تک نیز در پروژه‌های خاص می‌تواند به‌جای محدود کردن کارفرما به یک محصول آماده، نیاز پروژه را بررسی کرده و قابلیت‌های موردنیاز را به‌عنوان یک پروژه طراحی و توسعه سفارشی تعریف کند.
از یک دستگاه ساده تا یک پلتفرم سازمانی
یکی از مزیت‌های مهم در طراحی پروژه‌های سازمانی این است که می‌توان سیستم را متناسب با اندازه پروژه تعریف کرد.
برای یک پروژه کوچک ممکن است:
اکسس کنترل + ریموت تنظیمات
کاملاً کافی باشد.
برای پروژه‌ای بزرگ‌تر می‌توان:
اکسس کنترل چندخروجی + کارت + اثر انگشت + ریموت
را در نظر گرفت.
و در پروژه‌های پیچیده‌تر می‌توان قابلیت‌هایی مانند:
اپلیکیشن اندروید + مدیریت تحت وب + گزارش‌گیری + مدیریت چند ساختمان
را به معماری پروژه اضافه کرد.
در بازار Enterprise نیز معماری‌های قابل توسعه، مدیریت مرکزی، چندسایتی و امکان اتصال به سیستم‌های دیگر از ویژگی‌های کلیدی راهکارهای سازمانی محسوب می‌شوند.
هدف از طراحی اکسس کنترل سازمانی چیست؟
هدف نهایی فقط این نیست که «در باز شود یا بسته بماند».
هدف این است که سازمان بتواند مشخص کند:
چه کسی؟
کجا؟
چه زمانی؟
با چه سطح دسترسی؟
و در صورت نیاز:
با چه سابقه‌ای؟
به بخش‌های مختلف مجموعه دسترسی داشته باشد.
هرچه سازمان بزرگ‌تر باشد، اهمیت این چهار محور بیشتر می‌شود.
به همین دلیل یک سیستم سازمانی خوب باید از ابتدا بر اساس سناریوی واقعی تردد سازمان طراحی شود، نه صرفاً بر اساس تعداد درها یا تعداد کارت‌خوان‌ها.
معماری اکسس کنترل برای یک پروژه سازمانی بزرگ
وقتی صحبت از یک پروژه سازمانی بزرگ می‌شود، دیگر نمی‌توان اکسس کنترل را به‌صورت چند دستگاه مستقل در نظر گرفت.
فرض کنید یک مجموعه شامل:
- چند بلوک ساختمانی
- چندین آسانسور در هر بلوک
- پارکینگ مشترک بین بلوک‌ها
- ورودی اصلی مجموعه
- ورودی‌های فرعی
- نگهبانی
- ساختمان‌های اداری یا سازمانی
- فضاهای اختصاصی و حساس
- کارکنان، مدیران، مهمانان و پیمانکاران
باشد.
در چنین پروژه‌ای، اگر برای هر ساختمان یک سیستم کاملاً مستقل طراحی شود، مدیریت کاربران و دسترسی‌ها به‌تدریج پیچیده خواهد شد.
راهکار مهندسی بهتر این است که ابتدا معماری کل پروژه مشخص شود و سپس تجهیزات، کنترلرها و نرم‌افزار متناسب با آن انتخاب یا طراحی شوند.
در راهکارهای Enterprise امروزی نیز هدف اصلی، ایجاد یک لایه مدیریت یکپارچه برای ساختمان‌ها و نقاط کنترل مختلف است؛ به‌گونه‌ای که سیاست‌های دسترسی، کاربران و گزارش‌ها از یک ساختار مرکزی قابل مدیریت باشند.
یک مثال واقعی از مقیاس پروژه سازمانی
برای درک بهتر موضوع، مجموعه‌ای را تصور کنید که چند بلوک ساختمانی دارد.
در هر بلوک ممکن است چندین آسانسور وجود داشته باشد؛ برای مثال حتی ۹ آسانسور در یک بلوک.
از طرف دیگر، پارکینگ تمام بلوک‌ها می‌تواند مشترک باشد.
در چنین پروژه‌ای دیگر نمی‌توان فقط پرسید:
«برای هر آسانسور چه اکسس کنترلی نصب کنیم؟»
بلکه باید مجموعه‌ای از سؤال‌ها پاسخ داده شوند:
- کاربر متعلق به کدام بخش سازمان است؟
- به کدام ساختمان دسترسی دارد؟
- از کدام آسانسورها می‌تواند استفاده کند؟
- به کدام طبقات مجاز است؟
- آیا به پارکینگ دسترسی دارد؟
- آیا به ورودی‌های خاص دسترسی دارد؟
- مهمان او چگونه وارد مجموعه می‌شود؟
- پیمانکار چگونه دسترسی می‌گیرد؟
- اگر کارمند سازمان تغییر سمت دهد چه اتفاقی می‌افتد؟
- اگر کارت او گم شود چگونه غیرفعال می‌شود؟
- چه کسی می‌تواند این دسترسی‌ها را مدیریت کند؟
- گزارش رویدادها کجا ثبت می‌شود؟
- این همان تفاوت میان چند دستگاه اکسس کنترل و یک راهکار کنترل تردد سازمانی است.
وقتی چند بلوک و چند آسانسور داریم
در یک مجموعه بزرگ ممکن است هر بلوک تعداد زیادی آسانسور داشته باشد.
برای مثال:
اما ممکن است کاربران بین این بلوک‌ها نیز تردد داشته باشند.
در این شرایط باید ساختار دسترسی به‌گونه‌ای تعریف شود که بتوان برای هر کاربر یا گروه کاربری مشخص کرد:
برای نمونه:
کارمند واحد فناوری اطلاعات → بلوک A + بلوک B → طبقات مشخص
یا:
مدیر ارشد → تمام بلوک‌ها و طبقات مجاز
یا:
پیمانکار → فقط بلوک B → فقط طبقه ۶ → در بازه زمانی مشخص
این نوع تفکیک در سیستم‌های سازمانی مدرن نیز به‌عنوان کنترل دسترسی بر اساس نقش، طبقه، ساختمان و زمان مورد استفاده قرار می‌گیرد.
پارکینگ مشترک بین چند ساختمان چگونه مدیریت می‌شود؟
یکی از چالش‌های مهم پروژه‌های بزرگ، پارکینگ مشترک است.
فرض کنید چند بلوک یک مجموعه از پارکینگ مشترکی استفاده می‌کنند.
در این حالت، پارکینگ دیگر متعلق به یک ساختمان مشخص نیست؛ بلکه یک بخش مشترک از زیرساخت مجموعه است.
بنابراین ممکن است یک کاربر:
از ورودی مجموعه وارد شود → وارد پارکینگ شود → خودرو را پارک کند → به آسانسور مربوط به بلوک خود برسد → فقط به طبقات مجاز دسترسی داشته باشد.
در چنین سناریویی، کنترل پارکینگ و کنترل آسانسور باید از نظر سیاست دسترسی با یکدیگر هماهنگ باشند.
این به معنی آن نیست که الزاماً تمام تجهیزات باید یک دستگاه واحد باشند؛ بلکه باید معماری کلی سیستم به‌گونه‌ای طراحی شود که هر بخش وظیفه خود را انجام دهد و در صورت نیاز، اطلاعات و سیاست‌های دسترسی بین بخش‌ها هماهنگ شوند.
راهکارهای سازمانی موجود نیز معمولاً کنترل پارکینگ، آسانسور، ورودی و سایر نقاط کنترل را در یک معماری مدیریت دسترسی بزرگ‌تر قرار می‌دهند.
کنترل تردد از ورودی مجموعه تا طبقه مقصد
در یک پروژه سازمانی بزرگ، نباید هر نقطه کنترل را جداگانه بررسی کرد.
بهتر است مسیر کامل کاربر طراحی شود.
برای مثال:
ورودی اصلی مجموعه
↓
کنترل خودرو یا ورودی
↓
پارکینگ
↓
لابی بلوک
↓
کارت‌خوان یا روش شناسایی
↓
آسانسور
↓
طبقه مجاز
این نگاه باعث می‌شود نقاط ضعف احتمالی سیستم بهتر مشخص شوند.
برای مثال اگر ورودی اصلی کاملاً کنترل شده باشد ولی هر فردی بتواند پس از ورود به هر طبقه‌ای از آسانسور دسترسی داشته باشد، بخشی از سیاست امنیتی مجموعه عملاً ناقص خواهد بود.
به همین دلیل کنترل دسترسی آسانسور در پروژه‌های بزرگ باید بخشی از معماری کلی کنترل تردد باشد، نه یک تجهیز جانبی.
کنترل طبقات آسانسور در یک مجموعه سازمانی
فرض کنید یک کارمند فقط در بلوک A و طبقات ۳ و ۴ فعالیت می‌کند.
هنگام شناسایی او در آسانسور، سیستم باید بتواند بر اساس مجوز تعریف‌شده، دسترسی او را محدود کند.
در مقابل، مدیر مجموعه ممکن است:
- تمام بلوک‌ها
- تمام آسانسورها
- طبقات مدیریتی
- پارکینگ
را در اختیار داشته باشد.
این همان مفهوم Floor-Level Access Control است؛ یعنی مجوز دسترسی نه فقط برای ورود به ساختمان، بلکه برای رسیدن به طبقه مشخص تعریف می‌شود. این قابلیت در راهکارهای تجاری کنترل آسانسور نیز به‌عنوان یکی از اجزای اصلی کنترل دسترسی سازمانی مطرح است.
آیا یک کاربر می‌تواند به چند آسانسور دسترسی داشته باشد؟
بله، در معماری مناسب این امکان وجود دارد.
برای مثال یک کارمند ممکن است بتواند از:
- آسانسورهای بلوک A
- آسانسورهای بلوک B
استفاده کند، اما فقط به طبقات مشخصی دسترسی داشته باشد.
در مقابل ممکن است کاربری فقط مجاز به استفاده از آسانسورهای یک بلوک باشد.
بنابراین تعداد آسانسورها نباید باعث شود برای هر آسانسور یک دنیای مدیریتی مستقل ایجاد شود.
ساختار کاربران و مجوزها باید در سطح پروژه تعریف شود و سپس به نقاط کنترل مربوطه اعمال شود.
مدیریت مرکزی کاربران در پروژه‌های چندبلوک
فرض کنید سازمان ۱۵۰۰ کاربر دارد.
اگر برای هر بلوک یک سیستم کاملاً جداگانه وجود داشته باشد، تغییر وضعیت یک کارمند می‌تواند نیازمند تغییرات در چند سیستم مختلف باشد.
اما در یک معماری متمرکز، می‌توان کاربر را در ساختار اصلی تعریف کرد و مجوزهای او را مشخص نمود.
برای مثال:
مهندس رضایی
- ساختمان A: مجاز
- ساختمان B: مجاز
- ساختمان C: غیرمجاز
- پارکینگ: مجاز
- طبقات ۳، ۴ و ۷: مجاز
- آسانسورها: گروه A و B
- دسترسی خارج از ساعات اداری: غیرمجاز
این مدل مدیریت، در پروژه‌های بزرگ بسیار قابل کنترل‌تر از مدیریت مستقل هر دستگاه است.
راهکارهای Enterprise نیز دقیقاً روی همین مفهوم «یک منبع مرکزی برای کاربران، نقش‌ها و سیاست‌های دسترسی» تأکید دارند.
نقش حراست و مدیریت امنیت در پروژه سازمانی
در پروژه‌های سازمانی بزرگ، معمولاً همه کاربران نباید اختیار یکسانی برای مدیریت سیستم داشته باشند.
برای مثال می‌توان نقش‌های مدیریتی متفاوتی تعریف کرد:
مدیر سیستم
دسترسی کامل به تنظیمات سیستم.
حراست
مدیریت کاربران، رویدادها و دسترسی‌های امنیتی.
مدیر ساختمان
مدیریت محدوده مشخصی از ساختمان.
مسئول منابع انسانی
مدیریت اطلاعات پرسنلی مرتبط با دسترسی.
اپراتور
دسترسی محدود به امکانات روزمره.
این تفکیک باعث می‌شود مدیریت سیستم خودش به یک نقطه ضعف امنیتی تبدیل نشود.
در سیستم‌های Enterprise نیز Role-Based Access Control برای محدود کردن اختیار مدیران و اپراتورها به بخش‌های مجاز، یک اصل مهم طراحی محسوب می‌شود.
مهمان یک سازمان بزرگ چگونه مدیریت می‌شود؟
در یک مجموعه کوچک ممکن است نگهبان به‌صورت دستی با یک تماس تلفنی اجازه ورود مهمان را صادر کند.
اما در یک مجموعه بزرگ تعداد مراجعه‌کنندگان می‌تواند بسیار زیاد باشد.
برای مثال:
مهمان مدیرعامل
مهمان واحد مالی
پیمانکار شرکت تأسیسات
تکنسین شبکه
مراجعه‌کننده یک واحد سازمانی
هرکدام ممکن است سطح دسترسی متفاوتی داشته باشند.
یک معماری حرفه‌ای می‌تواند دسترسی مهمان را محدود به:
- ساختمان مشخص
- طبقه مشخص
- آسانسور مشخص
- بازه زمانی مشخص
کند.
راهکارهای سازمانی فعلی نیز Visitor Management را در کنار کنترل آسانسور، خودرو و سایر نقاط کنترل قرار می‌دهند.
پیمانکاران در پروژه‌های سازمانی
پیمانکار معمولاً یکی از پیچیده‌ترین گروه‌های کاربری است.
چون ممکن است:
- کارمند دائمی سازمان نباشد؛
- فقط چند روز در مجموعه حضور داشته باشد؛
- فقط به یک بخش خاص نیاز داشته باشد؛
- به طبقات حساس دسترسی نداشته باشد؛
- در ساعات خاصی اجازه ورود داشته باشد.
برای مثال:
پیمانکار سیستم تهویه → ساختمان B → موتورخانه → شنبه تا سه‌شنبه → ساعت ۹ تا ۱۴
یا:
پیمانکار شبکه → ساختمان مرکزی → اتاق سرور → فقط در زمان اعلام‌شده
در چنین سناریویی credential پیمانکار باید از ابتدا به‌عنوان یک دسترسی محدود و قابل مدیریت تعریف شود.
وقتی یک کارمند از یک ساختمان به ساختمان دیگر منتقل می‌شود
در سازمان‌های بزرگ، جابه‌جایی پرسنل اتفاقی طبیعی است.
فرض کنید کارمندی از ساختمان A به ساختمان C منتقل شود.
اگر سیستم به‌صورت مستقل برای هر ساختمان طراحی شده باشد، ممکن است مسئولان مجبور شوند:
- کاربر را از سیستم A حذف کنند.
- اطلاعات او را در سیستم C وارد کنند.
- مجوزهای جدید تعریف کنند.
- credential را دوباره تنظیم کنند.
اما در معماری متمرکز، می‌توان ساختار دسترسی کاربر را تغییر داد.
این موضوع علاوه بر کاهش کار مدیریتی، احتمال باقی ماندن دسترسی‌های قدیمی و ناخواسته را نیز کاهش می‌دهد.
مدیریت چرخه عمر credential، از فعال‌سازی تا تعلیق و حذف، یکی از موضوعات مهم در راهکارهای سازمانی محسوب می‌شود.
اگر کارت یک کارمند گم شود چه می‌شود؟
در پروژه‌ای با صدها یا هزاران کاربر، گم شدن یک کارت نباید باعث تغییر سیستم برای تمام کاربران شود.
مدیر باید بتواند credential مربوط به همان فرد را:
تعلیق کند
یا
حذف کند
و در صورت نیاز credential جدیدی برای او تعریف کند.
این قابلیت در پروژه‌های سازمانی اهمیت بسیار بیشتری نسبت به ساختمان‌های کوچک دارد؛ زیرا تعداد credentialها زیاد است و مدیریت دستی آنها می‌تواند خطاپذیر شود.
تعلیق دسترسی در پروژه‌های سازمانی
در همه شرایط لازم نیست credential را فوراً از حافظه سیستم حذف کنیم.
گاهی بهتر است دسترسی یک کاربر موقتاً تعلیق شود.
برای مثال:
- کارمند به مرخصی طولانی رفته است.
- پیمانکار فعلاً نباید وارد مجموعه شود.
- دسترسی یک بخش موقتاً محدود شده است.
- کاربر باید تا زمان مشخصی غیرفعال باشد.
در چنین شرایطی، تعلیق می‌تواند از حذف کامل credential مناسب‌تر باشد.
البته اینکه یک سیستم قابلیت تعلیق دارد یا خیر، به معماری همان محصول بستگی دارد و نباید این قابلیت را به تمام اکسس کنترل‌های موجود نسبت داد.
گزارش‌گیری در پروژه‌های چندساختمانی
در یک پروژه بزرگ، صرفاً «مجاز یا غیرمجاز بودن» کافی نیست.
در صورت وجود زیرساخت لازم، مدیران ممکن است بخواهند بدانند:
- چه کسی شناسایی شده است؟
- چه زمانی؟
- در کدام ساختمان؟
- در کدام نقطه کنترل؟
- از کدام روش شناسایی؟
- آیا دسترسی پذیرفته یا رد شده است؟
این اطلاعات می‌تواند برای:
- بررسی رخدادهای امنیتی
- مدیریت سازمان
- تحلیل تردد
- بررسی مشکلات
- گزارش‌دهی
مورد استفاده قرار گیرد.
در راهکارهای Enterprise، audit trail و گزارش‌گیری متمرکز معمولاً از قابلیت‌های مهم مدیریت سیستم محسوب می‌شوند.
داشبورد مرکزی برای مدیریت کل مجموعه
وقتی تعداد ساختمان‌ها و نقاط کنترل زیاد می‌شود، مدیریت با چند نرم‌افزار و دستگاه مستقل دشوار خواهد شد.
یک داشبورد مرکزی می‌تواند اطلاعات مربوط به بخش‌های مختلف را در یک محیط مدیریتی نمایش دهد.
برای مثال:
ساختمان A
- ۹ آسانسور
- ورودی‌ها
- کاربران
- رخدادها
ساختمان B
- ۶ آسانسور
- ورودی‌ها
- کاربران
- رخدادها
پارکینگ مشترک
- ورودی
- خروجی
- کاربران مجاز
در معماری‌های Enterprise، داشبورد مرکزی برای مدیریت چند سایت و مشاهده رخدادها یکی از الگوهای رایج است.
اپلیکیشن یا سامانه تحت وب در پروژه‌های سازمانی
در پروژه‌های بزرگ ممکن است مدیریت سیستم از یک کامپیوتر داخل ساختمان کافی نباشد.
در چنین شرایطی می‌توان در قالب یک پروژه سفارشی، امکاناتی مانند:
- مدیریت کاربران
- تعریف سطح دسترسی
- مدیریت ساختمان‌ها
- مدیریت آسانسورها
- مدیریت credentialها
- گزارش‌گیری
- مشاهده وضعیت سیستم
- مدیریت مهمان
- مدیریت پیمانکار
را در یک اپلیکیشن یا سامانه تحت وب در نظر گرفت.
اما یک نکته مهم وجود دارد:
اپلیکیشن یا وب‌سرور نباید صرفاً برای «مدرن به نظر رسیدن» به پروژه اضافه شود.
اگر سازمان واقعاً به مدیریت متمرکز از راه دور، چندکاربره یا گزارش‌گیری نیاز ندارد، یک سیستم ساده‌تر می‌تواند انتخاب اقتصادی‌تری باشد.
طراحی خوب یعنی امکانات بر اساس نیاز پروژه انتخاب شوند.
آیا پروژه سازمانی حتماً به Cloud نیاز دارد؟
خیر.
«سازمانی بودن» الزاماً به معنی Cloud بودن سیستم نیست.
بسته به سیاست سازمان و زیرساخت موجود، می‌توان معماری‌های مختلفی را بررسی کرد:
- سیستم محلی
- شبکه داخلی سازمان
- سرور داخلی
- سامانه تحت وب در شبکه سازمان
- Private Cloud
- Cloud
انتخاب معماری باید بر اساس عواملی مانند:
- سیاست امنیت اطلاعات
- زیرساخت شبکه
- دسترسی اینترنت
- سیاست سازمان
- تعداد سایت‌ها
- نیاز به مدیریت از راه دور
- الزامات نگهداری اطلاعات
انجام شود.
برخی پلتفرم‌های Enterprise نیز امکان استقرار Cloud، Private Cloud یا On-Premise را ارائه می‌کنند.
بنابراین نباید به کارفرما یک معماری خاص را بدون بررسی نیازهای واقعی پروژه تحمیل کرد.
اتصال اکسس کنترل سازمانی به سایر سیستم‌ها
در پروژه‌های بزرگ ممکن است اکسس کنترل تنها یکی از اجزای سیستم امنیتی سازمان باشد.
برای مثال ممکن است نیاز به هماهنگی با:
- دوربین مداربسته
- سیستم پلاک‌خوان
- پارکینگ
- نگهبانی
- اینترکام
- سیستم اعلام حریق
- BMS
- منابع انسانی
- سیستم مدیریت ساختمان
وجود داشته باشد.
راهکارهای Enterprise نیز معمولاً قابلیت یکپارچه‌سازی با سیستم‌های دیگر را یکی از مزیت‌های مهم معماری خود می‌دانند.
اما در اینجا باید بین دو موضوع تفاوت قائل شد:
«قابلیت فنی برای توسعه»
و
«اتصال آماده به یک سیستم خاص»
این دو الزاماً یکسان نیستند.
اگر پروژه به اتصال خاصی نیاز داشته باشد، باید آن نیاز در مرحله طراحی بررسی شود.
وقتی سازمان تجهیزات موجود دارد
گاهی کارفرما نمی‌خواهد تمام سیستم‌های فعلی را تعویض کند.
ممکن است:
- پنل‌های شستی موجود باشند؛
- آسانسورها از قبل نصب شده باشند؛
- جک‌های پارکینگ وجود داشته باشند؛
- تجهیزات کنترل ورود نصب شده باشند؛
- دوربین‌های پلاک‌خوان موجود باشند.
در این شرایط، طراحی پروژه باید از نقطه صفر شروع نشود.
ابتدا باید مشخص شود چه تجهیزاتی قابل استفاده مجدد هستند و سیستم جدید چگونه می‌تواند با آنها هماهنگ شود.
این موضوع به‌خصوص در پروژه‌های بازسازی و ارتقای ساختمان اهمیت زیادی دارد.
طراحی اکسس کنترل برای آسانسورهای موجود
یکی از مزیت‌های مهم راهکارهای سفارشی این است که الزاماً قرار نیست آسانسور از ابتدا ساخته شود.
در بسیاری از پروژه‌ها، هدف این است که:
آسانسور موجود → به سیستم کنترل دسترسی مجهز شود
بدون تغییر غیرضروری در ساختار اصلی کابین.
در اینجا طراحی باید بر اساس نوع پنل شستی، کلیدهای موجود، مدار فرمان آسانسور، روش کنترل طبقات و فضای نصب تجهیزات انجام شود.
در پروژه‌هایی که ظاهر کابین اهمیت دارد، حتی می‌توان اکسس کنترل را در طراحی پنل شستی جدید ادغام کرد.
این موضوع برای پروژه‌های سازمانی لوکس یا ساختمان‌هایی که نیاز به بازطراحی پنل دارند، اهمیت زیادی دارد.
طراحی پنل شستی مجهز به اکسس کنترل برای پروژه سازمانی
در برخی پروژه‌ها، کارفرما فقط یک سیستم کنترل تردد نمی‌خواهد؛ بلکه می‌خواهد خود پنل آسانسور نیز متناسب با پروژه طراحی شود.
در چنین شرایطی می‌توان در طراحی پنل مواردی مانند:
- کارت‌خوان RFID
- اثر انگشت
- کلیدهای لمسی
- کلیدهای فشاری
- نمایشگر
- تلفن اضطراری
- اکسس کنترل داخلی
- سایر تجهیزات موردنیاز پروژه
را از ابتدا در نظر گرفت.
در نتیجه، اکسس کنترل به‌صورت یک دستگاه اضافه روی پنل دیده نمی‌شود؛ بلکه می‌تواند بخشی از طراحی یکپارچه پنل کابین یا طبقه باشد.
این همان نقطه‌ای است که تجربه طراحی و تولید پنل آسانسور می‌تواند در یک پروژه سازمانی مزیت ایجاد کند.
یک پروژه سازمانی ممکن است از یک دستگاه شروع شود
گاهی کارفرما تصور می‌کند برای شروع پروژه باید یک سامانه بسیار بزرگ خریداری کند.
در حالی که می‌توان پروژه را مرحله‌بندی کرد.
مثلاً:
مرحله اول
کنترل دسترسی یک ساختمان و چند آسانسور.
مرحله دوم
اضافه شدن ساختمان دوم.
مرحله سوم
اتصال پارکینگ.
مرحله چهارم
افزودن گزارش‌گیری.
مرحله پنجم
توسعه اپلیکیشن یا سامانه تحت وب.
این مدل باعث می‌شود سازمان متناسب با نیاز و بودجه خود پروژه را توسعه دهد.
البته این مرحله‌بندی باید از ابتدای طراحی معماری پیش‌بینی شود؛ زیرا اگر سیستم اولیه هیچ ظرفیت توسعه‌ای نداشته باشد، توسعه در آینده ممکن است هزینه بیشتری ایجاد کند.
یک پروژه سازمانی بزرگ چگونه برآورد می‌شود؟
برای قیمت‌گذاری یک پروژه بزرگ نمی‌توان فقط پرسید:
«قیمت هر دستگاه اکسس کنترل چقدر است؟»
ابتدا باید ابعاد پروژه مشخص شود.
برای مثال:
زیرساخت ساختمان
- تعداد ساختمان‌ها
- تعداد بلوک‌ها
- تعداد طبقات
- تعداد آسانسورها
نقاط کنترل
- ورودی‌ها
- آسانسورها
- پارکینگ
- فضاهای حساس
کاربران
- تعداد کارکنان
- مدیران
- پیمانکاران
- مهمانان
روش شناسایی
نرم‌افزار
- مدیریت محلی
- اپلیکیشن
- سامانه تحت وب
- گزارش‌گیری
توسعه سفارشی
- پنل اختصاصی
- ارتباط با تجهیزات موجود
- قابلیت‌های خاص سازمان
- یکپارچه‌سازی
پس از مشخص شدن این موارد، می‌توان معماری و برآورد پروژه را انجام داد.
پروژه سازمانی بزرگ الزاماً گران‌ترین سیستم را نمی‌خواهد
این نکته برای فروش بسیار مهم است.
ممکن است یک سازمان بزرگ فقط به کنترل ساده طبقات نیاز داشته باشد.
در این حالت، اضافه کردن امکانات غیرضروری باعث افزایش هزینه پروژه می‌شود.
از طرف دیگر، ممکن است سازمانی کوچک باشد اما یک بخش بسیار حساس داشته باشد که نیازمند سطح بالاتری از کنترل دسترسی است.
بنابراین اندازه سازمان به‌تنهایی تعیین‌کننده پیچیدگی سیستم نیست.
آنچه معماری را تعیین می‌کند، ترکیبی از:
تعداد کاربران + تعداد نقاط کنترل + سطح امنیت + ساختار سازمان + نیاز نرم‌افزاری + قابلیت توسعه
است.
چه زمانی باید پروژه را سفارشی طراحی کرد؟
اگر پروژه فقط به یک کارت‌خوان استاندارد نیاز دارد، محصول آماده می‌تواند انتخاب مناسبی باشد.
اما اگر نیاز پروژه شامل ترکیبی از موارد زیر باشد:
- چند بلوک
- چند آسانسور
- پارکینگ مشترک
- چند گروه کاربری
- سطح دسترسی پیچیده
- مهمان
- پیمانکار
- گزارش‌گیری
- اپلیکیشن
- سامانه تحت وب
- پنل شستی اختصاصی
- اتصال به تجهیزات موجود
- قابلیت‌های اختصاصی سازمان
باشد، بهتر است پروژه قبل از خرید تجهیزات مهندسی و طراحی شود.
در این شرایط، اکسس کنترل دیگر فقط یک محصول نیست؛
بخشی از زیرساخت کنترل تردد سازمان است.
نوین کیا تک؛ از طراحی پنل آسانسور تا طراحی راهکار کنترل تردد
یکی از تفاوت‌های مهم نوین کیا تک در پروژه‌های سفارشی، نگاه صرفاً تجهیزمحور نیست.
در یک پروژه سازمانی ممکن است مسئله فقط انتخاب یک کارت‌خوان نباشد.
ممکن است لازم باشد:
- پنل شستی طراحی شود
- روش شناسایی انتخاب شود
- تعداد خروجی‌ها مشخص شود
- سطح دسترسی تعریف شود
- آسانسورها و طبقات در معماری پروژه قرار گیرند
- پارکینگ در نظر گرفته شود
- ریموت یا روش‌های دسترسی خاص طراحی شود
- اپلیکیشن توسعه داده شود
- سامانه تحت وب طراحی شود
یا حتی بخشی از قابلیت‌های سیستم برای نیاز خاص کارفرما توسعه پیدا کند.
این همان جایی است که یک پروژه سازمانی می‌تواند از خرید تجهیزات به طراحی یک راهکار اختصاصی تبدیل شود.
اگر پروژه شما از یک ساختمان معمولی بزرگ‌تر است
اگر پروژه شما شامل چند ساختمان، چند بلوک، چند آسانسور، پارکینگ، ورودی‌های متعدد یا تعداد زیادی کاربر است، پیشنهاد می‌کنیم قبل از انتخاب تجهیزات، ابتدا سناریوی کامل کنترل تردد پروژه بررسی شود.
نوین کیا تک می‌تواند پروژه را از نظر پنل آسانسور، روش شناسایی، کنترل طبقات، ساختار کاربران، پارکینگ، مدیریت ریموت، گزارش‌گیری و توسعه نرم‌افزاری بررسی کند و در صورت نیاز، راهکار سفارشی متناسب با پروژه پیشنهاد دهد.
برای بررسی پروژه سازمانی، مشخصات مجموعه، تعداد ساختمان‌ها، تعداد آسانسورها، تعداد کاربران و نیازهای کنترلی خود را برای کارشناسان نوین کیا تک ارسال کنید.
جمع‌بندی تا اینجا
در یک پروژه سازمانی بزرگ، اکسس کنترل نباید مجموعه‌ای از دستگاه‌های مستقل دیده شود.
از یک کاربر که وارد مجموعه می‌شود تا زمانی که به طبقه مقصد می‌رسد، باید یک زنجیره کامل در نظر گرفته شود:
ورودی مجموعه → ساختمان → پارکینگ → لابی → آسانسور → طبقه مقصد
در مجموعه‌های چندبلوک و چندآسانسوره، این زنجیره باید با ساختار سازمان، نقش کاربران، زمان دسترسی و سیاست‌های امنیتی هماهنگ باشد.
در پروژه‌های بزرگ‌تر نیز می‌توان مدیریت کاربران، ساختمان‌ها، آسانسورها، پارکینگ، مهمانان، پیمانکاران و گزارش‌ها را در یک معماری متمرکز قرار داد.
اما مهم‌تر از همه این است که هر پروژه باید بر اساس نیاز واقعی خودش طراحی شود.
یک سیستم سازمانی خوب الزاماً پیچیده‌ترین سیستم نیست؛ سیستمی است که امروز نیاز سازمان را پاسخ دهد و در صورت نیاز، فردا نیز قابلیت توسعه داشته باشد.
انتخاب روش شناسایی در اکسس کنترل پروژه‌های سازمانی
یکی از اولین تصمیم‌ها در طراحی اکسس کنترل یک پروژه سازمانی این است که کاربران چگونه شناسایی شوند.
پاسخ این سؤال همیشه «کارت» نیست.
بسته به نوع پروژه، تعداد کاربران، سطح امنیت، سهولت استفاده، بودجه و نوع نقاط کنترل می‌توان از روش‌های مختلفی استفاده کرد:
- کارت یا تگ RFID
- اثر انگشت
- رمز
- ریموت کنترل
- تلفن همراه و credential موبایلی
- روش‌های بیومتریک دیگر
- یا ترکیبی از چند روش
در راهکارهای حرفه‌ای کنترل دسترسی آسانسور نیز استفاده از RFID، بیومتریک، PIN و credential موبایلی در کنار امکان تعریف دسترسی برای طبقات مختلف دیده می‌شود.
اما انتخاب روش شناسایی باید از نیاز پروژه شروع شود، نه از امکانات یک دستگاه خاص.
اکسس کنترل کارتی برای پروژه‌های سازمانی
کارت و تگ RFID هنوز یکی از کاربردی‌ترین روش‌های شناسایی برای پروژه‌های بزرگ هستند.
دلیل آن ساده است:
- استفاده از آن برای کاربران راحت است.
- می‌توان credential را به یک فرد اختصاص داد.
- امکان تعریف سطح دسترسی وجود دارد.
- کارت یا تگ را می‌توان در تعداد زیاد مدیریت کرد.
- در صورت گم شدن، امکان غیرفعال کردن credential وجود دارد.
- می‌توان برای گروه‌های مختلف کاربران کارت‌های متفاوت تعریف کرد.
در پروژه‌ای با صدها یا هزاران کاربر، مهم‌تر از خود کارت، نحوه مدیریت کارت‌ها و مجوزهای آنها است.
برای مثال ممکن است یک کارت به یک کارمند اختصاص داده شود و دسترسی او شامل:
ورودی اصلی + پارکینگ + آسانسورهای ساختمان A + طبقات ۳ و ۴
باشد.
در حالی که کارت کارمند دیگری فقط:
ورودی اصلی + ساختمان B + طبقه ۵
را مجاز داشته باشد.
در معماری‌های سازمانی، همین تفکیک credential و مجوز است که سیستم را از یک کارت‌خوان ساده متمایز می‌کند.
اکسس کنترل اثر انگشتی برای سازمان‌ها
در برخی محیط‌های سازمانی، ممکن است کارفرما ترجیح دهد وابستگی به کارت و تگ کاهش پیدا کند.
در این شرایط اثر انگشت می‌تواند یکی از روش‌های شناسایی باشد.
مزیت اصلی آن این است که کاربر credential فیزیکی مانند کارت را همراه خود ندارد.
برای مثال:
کارکنان یک بخش حساس سازمان برای ورود به آن بخش از اثر انگشت استفاده می‌کنند.
یا:
برای دسترسی به طبقه مدیریتی، احراز هویت بیومتریک در نظر گرفته می‌شود.
البته اثر انگشت نیز برای تمام پروژه‌ها بهترین گزینه نیست.
در پروژه‌هایی با تعداد زیاد کاربر، شرایط محیطی خاص یا نیاز به سرعت بسیار بالا، باید قبل از انتخاب روش بیومتریک، شرایط واقعی استفاده بررسی شود.
بنابراین در طراحی حرفه‌ای، اثر انگشت یک گزینه است، نه یک الزام.
ترکیب کارت و اثر انگشت در یک پروژه
گاهی بهترین راهکار، انتخاب فقط یک روش شناسایی نیست.
ممکن است پروژه به یک سیستم ترکیبی نیاز داشته باشد.
برای مثال:
کارت → کاربران عادی
کارت + اثر انگشت → مدیران
روش احراز هویت قوی‌تر → فضاهای حساس
این معماری باعث می‌شود سطح امنیت متناسب با اهمیت هر بخش تعیین شود.
راهکارهای تجاری کنترل دسترسی نیز امکان استفاده از چند فناوری احراز هویت و حتی احراز هویت چندعاملی را برای نقاط حساس ارائه می‌کنند.
اکسس کنترل رمزی در پروژه سازمانی
رمز نیز می‌تواند در برخی پروژه‌ها کاربرد داشته باشد.
برای مثال:
- اتاق فنی
- اتاق تجهیزات
- ورودی محدود
- دسترسی موقت
- نقاطی که تعداد کاربران کم است
اما استفاده از یک رمز عمومی برای تمام کاربران با مدیریت credential اختصاصی تفاوت زیادی دارد.
در پروژه‌های سازمانی بهتر است تا حد امکان مشخص باشد چه فرد یا گروهی چه مجوزی دارد و در صورت تغییر شرایط، بتوان همان دسترسی را مدیریت کرد.
به همین دلیل رمز می‌تواند بخشی از راهکار باشد، اما معمولاً نباید بدون بررسی نیاز پروژه به‌عنوان تنها روش شناسایی برای تمام نقاط کنترل انتخاب شود.
آیا ریموت کنترل می‌تواند در پروژه سازمانی استفاده شود؟
بله؛ اما کاربرد آن باید دقیقاً مشخص باشد.
ریموت برای همه نقاط کنترل یک پروژه سازمانی جایگزین مناسبی برای کارت یا بیومتریک نیست.
ولی در سناریوهایی که سرعت و سهولت استفاده اهمیت دارد، می‌تواند بسیار کاربردی باشد.
برای مثال:
- احضار آسانسور
- دسترسی پارکینگ
- دسترسی مهمان
- لابیمن
- کاربردهای اختصاصی یک پروژه
در راهکارهای سفارشی حتی می‌توان برای هر ریموت شناسه مشخصی در نظر گرفت و آن را به کاربر یا واحد خاصی اختصاص داد.
این نوع قابلیت‌ها به‌خصوص در پروژه‌هایی که رفتار کاربران و ساختار ساختمان متفاوت از الگوی استاندارد است، ارزش زیادی پیدا می‌کنند.
احضار آسانسور با ریموت در پروژه‌های سازمانی
احضار آسانسور با ریموت را نباید با کنترل دسترسی طبقات یکی دانست.
این دو می‌توانند دو عملکرد مستقل باشند.
برای مثال:
احضار آسانسور → ریموت
اما:
اجازه انتخاب طبقات → کارت
در این حالت ریموت فقط باعث می‌شود کابین به نقطه موردنظر فراخوانی شود و سیستم کنترل طبقات همچنان مجوز حرکت کاربر را مدیریت کند.
این تفکیک می‌تواند در طراحی راهکارهای سفارشی بسیار مفید باشد؛ زیرا هر credential دقیقاً وظیفه‌ای را انجام می‌دهد که برای آن طراحی شده است.
ریموت میهمان و لابیمن در پروژه‌های سازمانی
در مجموعه‌هایی که مراجعه‌کننده یا مهمان زیاد دارند، دادن credential دائمی به مهمان معمولاً منطقی نیست.
به همین دلیل می‌توان برای مهمان یا لابیمن یک راهکار جداگانه تعریف کرد.
برای مثال:
دسترسی محدود به طبقه موردنظر → مهمان
امکان احضار آسانسور و آزادسازی دسترسی موردنیاز → لابیمن
این نوع تفکیک باعث می‌شود credential مهمان با credential دائمی کارکنان یا ساکنان یکسان نباشد.
در راهکارهای Enterprise نیز مدیریت visitor و contractor در کنار credentialهای دائمی یکی از اجزای مهم سیستم کنترل دسترسی محسوب می‌شود.
مدیریت دسترسی پیمانکاران
یکی از کاربردهای مهم اکسس کنترل سازمانی، مدیریت پیمانکاران است.
فرض کنید یک پیمانکار برای تعمیر تجهیزات آسانسور وارد مجموعه می‌شود.
او ممکن است فقط به:
- موتورخانه
- طبقه مشخص
- اتاق تجهیزات
- مسیر مشخص
نیاز داشته باشد.
نباید صرفاً به دلیل اینکه «پیمانکار است»، دسترسی او به تمام ساختمان آزاد شود.
بنابراین می‌توان credential او را با محدوده دسترسی موردنیاز تعریف کرد.
در سیستم‌های حرفه‌ای، دسترسی پیمانکاران و کاربران موقت می‌تواند بخشی از مدیریت چرخه عمر credential باشد.
تعریف سطح دسترسی برای گروه‌های مختلف کاربران
یکی از مهم‌ترین بخش‌های طراحی پروژه سازمانی، تعریف گروه‌های کاربری است.
برای مثال:
گروه مدیران
دسترسی گسترده به ساختمان‌ها و طبقات.
گروه کارکنان
دسترسی به ساختمان و طبقات مرتبط با محل کار.
گروه خدمات
دسترسی به بخش‌های خدماتی و فنی.
گروه حراست
دسترسی گسترده برای انجام وظایف امنیتی.
گروه پیمانکاران
دسترسی محدود و موقت.
گروه مهمانان
دسترسی محدود به محل مراجعه.
این ساختار بسیار بهتر از آن است که برای هر کاربر به‌صورت کاملاً جداگانه و بدون الگوی مشخص مجوز تعریف شود.
در سیستم‌های Enterprise، Role-Based Access Control دقیقاً برای همین هدف استفاده می‌شود: مجوزها بر اساس نقش، ساختار سازمانی و سیاست‌های دسترسی تعریف می‌شوند.
کنترل دسترسی بر اساس زمان
گاهی یک کاربر باید به یک طبقه دسترسی داشته باشد، اما نه در تمام ساعات.
برای مثال:
ساعت ۷ تا ۱۸ → شنبه تا چهارشنبه → طبقه اداری → کارمند
یا:
ساعت ۹ تا ۱۳ → فقط دوشنبه → موتورخانه → پیمانکار
در این شرایط، «چه کسی مجاز است؟» تنها سؤال سیستم نیست.
سؤال دوم این است:
چه زمانی مجاز است؟
کنترل دسترسی زمانی یکی از قابلیت‌های رایج در راهکارهای حرفه‌ای آسانسور و Enterprise است.
کنترل دسترسی بر اساس ساختمان و طبقه
در پروژه‌ای با چند بلوک، می‌توان سطح دسترسی را به‌صورت چندلایه تعریف کرد.
برای مثال:
طبقه → آسانسور → ساختمان → سازمان → کاربر
این ساختار برای پروژه‌های چندساختمانی بسیار مهم است.
ممکن است یک کارمند به ساختمان A دسترسی داشته باشد ولی به ساختمان B دسترسی نداشته باشد.
یا در یک ساختمان فقط طبقات مشخصی برای او مجاز باشند.
در راهکارهای حرفه‌ای کنترل آسانسور نیز اختصاص سطح دسترسی به طبقات برای کاربران و گروه‌ها از قابلیت‌های اصلی محسوب می‌شود.
مدیریت چرخه عمر کارت، تگ و credential
در یک پروژه سازمانی، تعریف credential فقط مرحله اول کار است.
یک credential ممکن است در طول عمر خود این مراحل را طی کند:
حذف → فعال‌سازی مجدد → تعلیق → تغییر مجوز → استفاده → فعال‌سازی → تعریف
برای مثال:
یک کارمند وارد سازمان می‌شود.
کارت او تعریف می‌شود.
پس از تغییر سمت، سطح دسترسی او تغییر می‌کند.
در زمان مرخصی طولانی ممکن است credential او موقتاً تعلیق شود.
پس از بازگشت، مجدداً فعال می‌شود.
و در پایان همکاری، credential او حذف می‌شود.
مدیریت چرخه عمر credential یکی از تفاوت‌های مهم سیستم‌های حرفه‌ای با سیستم‌های ساده و مستقل است.
حذف credential گمشده بدون حضور فیزیکی
گم شدن کارت، تگ یا سایر credentialها در سازمان‌های بزرگ اجتناب‌ناپذیر است.
مشکل اصلی زمانی ایجاد می‌شود که برای حذف آن credential، حضور فیزیکی کاربر یا دستگاه ضروری باشد.
در یک معماری مناسب می‌توان دسترسی credential گمشده را از سیستم مدیریت حذف یا تعلیق کرد.
در برخی راهکارها این مدیریت به‌صورت مرکزی و حتی از راه دور انجام می‌شود.
این قابلیت به‌خصوص برای سازمانی که تعداد زیادی کاربر و چند ساختمان دارد، ارزش عملیاتی زیادی دارد.
تعلیق credential چه تفاوتی با حذف آن دارد؟
این دو مفهوم باید از یکدیگر جدا شوند.
حذف
credential از فهرست مجاز سیستم حذف می‌شود.
تعلیق
credential همچنان به کاربر یا واحد مربوط است، اما موقتاً اجازه استفاده از آن وجود ندارد.
تعلیق زمانی کاربرد دارد که مدیر بخواهد:
- دسترسی موقتاً متوقف شود؛
- credential در آینده دوباره فعال شود؛
- اطلاعات کاربر حفظ شود؛
- نیاز به تعریف مجدد credential کاهش پیدا کند.
در طراحی سیستم‌های سفارشی می‌توان بر اساس نیاز پروژه، یکی یا هر دو قابلیت را در نظر گرفت.
آیا می‌توان چند credential برای یک کاربر تعریف کرد؟
بله، در معماری‌های مناسب می‌توان برای یک کاربر بیش از یک روش شناسایی تعریف کرد.
برای مثال:
کارمند شماره ۱۲۵
- کارت RFID
- اثر انگشت
- credential موبایلی
یا:
مدیر مجموعه
- کارت
- اثر انگشت
- ریموت اختصاصی
این قابلیت زمانی مفید است که کاربر در شرایط مختلف به روش‌های متفاوتی برای دسترسی نیاز داشته باشد.
برخی پلتفرم‌های Enterprise نیز پشتیبانی از چند credential برای یک کاربر را به‌عنوان بخشی از مدیریت متمرکز ارائه می‌کنند.
یک credential برای چند نقطه کنترل
در یک پروژه بزرگ بهتر است کاربر مجبور نباشد برای هر نقطه کنترل یک شناسه کاملاً مستقل داشته باشد، مگر اینکه از نظر امنیتی چنین چیزی لازم باشد.
برای مثال یک کارت می‌تواند در صورت طراحی مناسب برای:
ورودی ساختمان
↓
پارکینگ
↓
لابی
↓
آسانسور
استفاده شود.
اما مجوز آن در هر نقطه می‌تواند متفاوت باشد.
این همان مفهوم مهمی است که در راهکارهای یکپارچه مطرح می‌شود:
یک هویت، چند نقطه کنترل، مجوزهای متفاوت.
چه زمانی احراز هویت چندمرحله‌ای منطقی است؟
برای همه کاربران و همه نقاط کنترل لازم نیست احراز هویت چندمرحله‌ای استفاده شود.
اما برای نقاط حساس می‌تواند منطقی باشد.
برای مثال:
کارت + اثر انگشت
یا:
کارت + PIN
برای دسترسی به:
- اتاق سرور
- مرکز کنترل
- اتاق تجهیزات حساس
- بخش مدیریتی
- محل نگهداری اطلاعات حساس
می‌تواند در نظر گرفته شود.
راهکارهای Enterprise نیز برای مناطق حساس از Multi-Factor Authentication به‌عنوان یکی از روش‌های افزایش اطمینان از هویت کاربر استفاده می‌کنند.
امنیت فقط به نوع کارت بستگی ندارد
یکی از اشتباهات رایج در خرید اکسس کنترل این است که امنیت سیستم را فقط بر اساس نوع کارت یا کارت‌خوان قضاوت کنیم.
در یک پروژه واقعی باید کل زنجیره بررسی شود:
credential
↓
کارت‌خوان
↓
کنترلر
↓
منطق دسترسی
↓
نحوه مدیریت کاربران
↓
حفاظت از اطلاعات
↓
گزارش‌گیری
↓
فرآیند حذف و تعلیق
↓
مدیریت اپراتورها
ممکن است یک کارت بسیار مناسب باشد، اما اگر مدیریت credential ضعیف باشد، امنیت کل سیستم تحت تأثیر قرار گیرد.
بنابراین امنیت یک ویژگی سیستم است، نه فقط یک ویژگی کارت.
اکسس کنترل سازمانی با سیستم آماده یا راهکار سفارشی؟
در اینجا باید یک مرز مهم مشخص شود.
اگر نیاز پروژه این باشد:
«برای دو درب و یک آسانسور کارت‌خوان می‌خواهیم.»
احتمالاً محصول آماده بهترین انتخاب است.
اما اگر نیاز پروژه این باشد:
«چند بلوک، چندین آسانسور، پارکینگ مشترک، چند گروه کاربری، مهمان، پیمانکار، گزارش‌گیری و اتصال به سامانه سازمان داریم.»
دیگر باید قبل از انتخاب محصول، راهکار طراحی شود.
در این حالت ممکن است بخشی از سیستم آماده باشد و بخشی سفارشی توسعه پیدا کند.
این دقیقاً همان رویکردی است که در پروژه‌های پیچیده ارزش بیشتری دارد: استفاده از محصول آماده در جایی که کافی است و توسعه سفارشی فقط در جایی که واقعاً نیاز وجود دارد.
چرا توسعه سفارشی می‌تواند برای پروژه سازمانی ارزشمند باشد؟
- هر سازمان الزاماً شبیه سازمان دیگر نیست.
- ممکن است یک کارفرما بخواهد:
- ساختار واحدهای خودش را داشته باشد؛
- سطح دسترسی خاصی تعریف کند؛
- روش شناسایی ترکیبی داشته باشد؛
- پنل آسانسور اختصاصی طراحی کند؛
- ریموت اختصاصی داشته باشد؛
- اطلاعات کاربران با نرم‌افزار داخلی هماهنگ شود؛
- گزارش خاصی دریافت کند؛
- یا فرآیند مدیریت credential متفاوتی داشته باشد.
در این شرایط، استفاده از یک محصول کاملاً ثابت ممکن است سازمان را مجبور کند فرآیند کاری خود را با محصول تطبیق دهد.
اما در پروژه سفارشی، می‌توان ابتدا نیاز واقعی را تحلیل کرد و سپس معماری راهکار را متناسب با آن طراحی کرد.
قابلیت توسعه سفارشی؛ از یک تغییر کوچک تا یک سامانه سازمانی
توسعه سفارشی الزاماً به معنی ساخت یک سیستم کاملاً جدید نیست.
ممکن است پروژه فقط به یک قابلیت کوچک نیاز داشته باشد.
مثلاً:
- تغییر منطق دسترسی
- افزودن یک روش شناسایی
- تعریف سطح دسترسی خاص
- افزودن یک خروجی
- طراحی یک پنل اختصاصی
- افزودن گزارش
- مدیریت یک نوع credential خاص
در پروژه‌های بزرگ‌تر، همین توسعه می‌تواند به:
کنترل چند ساختمان + آسانسور + پارکینگ + کاربران + مهمان + گزارش‌گیری + سامانه تحت وب یا اپلیکیشن
تبدیل شود.
بنابراین بهتر است پروژه از ابتدا با نگاه معماری توسعه‌پذیر بررسی شود.
یک راهکار سازمانی خوب باید قابل توسعه باشد
ممکن است سازمان امروز ۳ ساختمان داشته باشد و چند سال بعد ساختمان‌های جدیدی به مجموعه اضافه شوند.
اگر معماری سیستم از ابتدا توسعه‌پذیر باشد، اضافه کردن ساختمان‌ها و نقاط کنترل ساده‌تر خواهد بود.
به همین دلیل در مرحله طراحی باید پرسید:
اگر تعداد کاربران دو برابر شد چه می‌شود؟
اگر ساختمان جدید اضافه شد چه می‌شود؟
اگر آسانسور جدید اضافه شد چه می‌شود؟
اگر سازمان به اپلیکیشن نیاز پیدا کرد چه می‌شود؟
اگر پارکینگ جدید اضافه شد چه می‌شود؟
پاسخ به این سؤال‌ها بخشی از مهندسی پروژه است، نه یک موضوع فرعی.
از کنترل یک آسانسور تا مدیریت یک مجموعه سازمانی
اکسس کنترل سازمانی می‌تواند در مقیاس‌های بسیار متفاوت اجرا شود.
مقیاس کوچک
یک ساختمان، یک آسانسور، چند ده کاربر.
مقیاس متوسط
یک مجموعه، چند آسانسور، پارکینگ و صدها کاربر.
مقیاس بزرگ
چند بلوک، تعداد زیادی آسانسور، پارکینگ مشترک، ورودی‌های متعدد و هزاران کاربر.
مقیاس سازمانی
چند سایت، کاربران متعدد، سطوح دسترسی مختلف، سامانه مدیریت، گزارش‌گیری و نیاز به یکپارچه‌سازی.
نکته مهم این است که روش طراحی باید متناسب با مقیاس پروژه تغییر کند.
روش شناسایی مناسب پروژه شما چیست؟
اگر بین کارت، تگ، اثر انگشت، رمز، ریموت، موبایل یا یک راهکار ترکیبی مردد هستید، بهتر است ابتدا ساختار پروژه بررسی شود.
نوین کیا تک می‌تواند بر اساس تعداد کاربران، تعداد آسانسورها، طبقات، ساختمان‌ها، پارکینگ، نوع کاربران و سطح امنیت موردنیاز، روش شناسایی مناسب را پیشنهاد دهد.
جمع‌بندی تا اینجا
در پروژه سازمانی، انتخاب اکسس کنترل از انتخاب یک کارت‌خوان شروع نمی‌شود؛ از تعریف هویت و سیاست دسترسی شروع می‌شود.
کارت، تگ، اثر انگشت، رمز، ریموت یا موبایل فقط ابزارهای شناسایی هستند.
آنچه یک سیستم حرفه‌ای را می‌سازد، این است که بتوان مشخص کرد:
چه کسی؟
کجا؟
در چه زمانی؟
با چه روشی؟
با چه سطح دسترسی؟
و مهم‌تر از آن:
اگر شرایط کاربر تغییر کرد، چگونه دسترسی او را تغییر دهیم؟
در یک پروژه سازمانی حرفه‌ای، credential باید از زمان تعریف تا تغییر، تعلیق و حذف قابل مدیریت باشد و در صورت نیاز بتوان این مدیریت را در سطح چند ساختمان و چند نقطه کنترل انجام داد.
یکپارچه‌سازی اکسس کنترل در پروژه‌های سازمانی
در یک پروژه سازمانی بزرگ، معمولاً چند سیستم مختلف همزمان در حال کار هستند:
- ورودی‌های اصلی
- درب‌های داخلی
- آسانسورها
- پارکینگ
- اتاق‌های حساس
- ورودی کارکنان
- ورودی مهمانان
- سیستم نگهبانی
- دوربین‌های نظارتی
- سامانه مدیریت کاربران
- نرم‌افزار منابع انسانی
- سامانه حضور و غیاب
- اپلیکیشن یا سامانه تحت وب
اگر هرکدام از این بخش‌ها کاملاً مستقل از دیگری کار کنند، مدیریت مجموعه به‌مرور پیچیده می‌شود.
در مقابل، در یک معماری یکپارچه می‌توان اطلاعات هویت و سطح دسترسی کاربران را در بخش‌های مختلف به‌صورت هماهنگ مدیریت کرد.
برای نمونه، یک کارمند می‌تواند با یک credential مشخص در ورودی ساختمان شناسایی شود، به پارکینگ دسترسی داشته باشد و فقط طبقات مشخصی از آسانسور برای او فعال شوند.
این مدل از یکپارچه‌سازی در راهکارهای Enterprise نیز به‌کار می‌رود و هدف آن ایجاد یک دید متمرکز نسبت به هویت، مجوزها و نقاط دسترسی است.
اتصال اکسس کنترل به آسانسور
آسانسور یکی از مهم‌ترین بخش‌های کنترل تردد در ساختمان‌های سازمانی است.
ممکن است فردی اجازه ورود به ساختمان را داشته باشد، اما مجاز به ورود به تمام طبقات نباشد.
برای مثال:
مجاز → ورودی ساختمان
مجاز → پارکینگ
مجاز → طبقات ۱ تا ۵
غیرمجاز → طبقات ۶ تا ۱۰
در چنین ساختاری، کنترل دسترسی آسانسور باید بتواند سطح دسترسی کاربر را در زمان استفاده از آسانسور اعمال کند.
در راهکارهای حرفه‌ای کنترل دسترسی آسانسور نیز امکان تعریف اینکه «چه کسی به کدام طبقه و در چه زمانی دسترسی داشته باشد» یکی از قابلیت‌های اصلی محسوب می‌شود.
کنترل دسترسی چند آسانسور در یک پروژه سازمانی
در پروژه‌های بزرگ ممکن است یک ساختمان چندین آسانسور داشته باشد.
در این حالت الزاماً همه کاربران نباید به همه آسانسورها دسترسی یکسان داشته باشند.
برای مثال:
- آسانسورهای عمومی
- آسانسور کارکنان
- آسانسور خدمات
- آسانسور بخش مدیریت
- آسانسور مخصوص بخش‌های خاص
ممکن است هرکدام سیاست دسترسی متفاوتی داشته باشند.
در یک پروژه سفارشی می‌توان ساختار دسترسی را متناسب با معماری ساختمان تعریف کرد.
حتی ممکن است یک کاربر در آسانسور شماره ۱ به طبقات خاصی دسترسی داشته باشد، در حالی که همان کاربر در آسانسور شماره ۲ مجوز متفاوتی داشته باشد.
بنابراین در پروژه‌های چندآسانسوره، صرفاً تعداد خروجی‌های سیستم اهمیت ندارد؛ منطق دسترسی و ارتباط بین کاربر، آسانسور و طبقه نیز باید در طراحی دیده شود.
کنترل تردد در ساختمان‌های چند بلوکی
پیچیدگی پروژه زمانی بیشتر می‌شود که سازمان دارای چند ساختمان یا بلوک باشد.
برای مثال:
بلوک A
- ورودی
- چند آسانسور
- طبقات اداری
بلوک B
- ورودی
- چند آسانسور
- واحدهای سازمانی
بلوک C
- ساختمان مدیریت
در این حالت می‌توان برای هر کاربر محدوده دسترسی تعریف کرد.
یک کارمند ممکن است فقط به بلوک A دسترسی داشته باشد.
مدیر یک مجموعه ممکن است به تمام بلوک‌ها دسترسی داشته باشد.
تیم تأسیسات نیز ممکن است فقط در ساعات مشخص به فضاهای فنی چند بلوک دسترسی داشته باشد.
در سیستم‌های سازمانی بزرگ، مدیریت متمرکز هویت و مجوزها برای چند سایت یا چند محل، یکی از مزیت‌های مهم معماری Enterprise محسوب می‌شود.
پارکینگ به‌عنوان بخشی از سیستم کنترل تردد سازمانی
پارکینگ را نباید یک سیستم کاملاً جدا از اکسس کنترل در نظر گرفت.
در یک پروژه سازمانی ممکن است ورود خودرو نیز بخشی از هویت کاربر باشد.
برای مثال:
ورود ساختمان → کارت یا credential → کارمند
و همزمان:
ورود پارکینگ → مجوز خودرو → کارمند
در پروژه‌های پیشرفته‌تر می‌توان از فناوری‌هایی مانند RFID، UHF یا پلاک‌خوان نیز برای شناسایی خودرو استفاده کرد.
در یک نمونه واقعی از راهکار یکپارچه کنترل دسترسی آسانسور، پارکینگ، مدیریت مهمان و کنترل طبقات، اطلاعات هویت و مجوزهای کاربر میان بخش‌های مختلف سیستم هماهنگ شده است.
ارتباط پارکینگ و آسانسور
یکی از سناریوهای مهم در ساختمان‌های سازمانی این است که دسترسی خودرو و دسترسی آسانسور با یکدیگر مرتبط باشند.
برای مثال:
یک کارمند با credential معتبر وارد پارکینگ می‌شود.
پس از پارک خودرو، وارد لابی آسانسور می‌شود.
سیستم می‌تواند بر اساس مجوز همان کاربر، طبقات مجاز را در اختیار او قرار دهد.
در چنین معماری‌ای، پارکینگ، ورودی و آسانسور سه سیستم کاملاً جدا از هم نیستند؛ بلکه می‌توانند بخشی از یک زنجیره کنترل تردد باشند.
این نوع یکپارچه‌سازی برای ساختمان‌های اداری بزرگ باعث کاهش پراکندگی سیستم‌ها و ساده‌تر شدن مدیریت می‌شود.
مدیریت مهمان در پروژه‌های سازمانی
مهمانان سازمانی معمولاً نباید همان دسترسی کارکنان را داشته باشند.
فرض کنید یک مراجعه‌کننده برای ملاقات با مدیر یک واحد سازمانی وارد ساختمان می‌شود.
فرآیند می‌تواند به شکل زیر طراحی شود:
ثبت مهمان
↓
تأیید توسط میزبان یا نگهبانی
↓
صدور دسترسی موقت
↓
ورود به ساختمان
↓
دسترسی به طبقه یا محل موردنظر
↓
پایان اعتبار دسترسی
در راهکارهای Enterprise، Visitor Management می‌تواند با سیستم کنترل دسترسی یکپارچه شود تا پس از ثبت و تأیید مهمان، دسترسی موقت متناسب با سیاست سازمان ایجاد شود و سوابق ورود و خروج نیز قابل ثبت باشد.
دسترسی موقت برای پیمانکاران و نیروهای خدماتی
در بسیاری از سازمان‌ها فقط کارمندان نیاز به دسترسی ندارند.
گروه‌های دیگری نیز وجود دارند:
- پیمانکاران
- نیروهای خدماتی
- تعمیرکاران
- کارشناسان شرکت‌های طرف قرارداد
- نیروهای نصب و نگهداری
- مهمانان ویژه
برای این افراد بهتر است credential دائمی صادر نشود، مگر اینکه واقعاً نیاز باشد.
برای مثال می‌توان دسترسی یک پیمانکار را فقط برای:
شنبه ساعت ۹ تا ۱۳
و فقط در:
پارکینگ + موتورخانه + طبقه مشخص
تعریف کرد.
پس از پایان زمان یا پروژه، دسترسی او غیرفعال می‌شود.
این مفهوم در سامانه‌های Enterprise با مدیریت چرخه عمر کاربران، پیمانکاران و مجوزهای فیزیکی دنبال می‌شود.
اتصال اکسس کنترل به سیستم منابع انسانی
در یک سازمان بزرگ، اطلاعات کارکنان معمولاً در یک سیستم منابع انسانی نگهداری می‌شود.
برای مثال:
- نام و نام خانوادگی
- کد پرسنلی
- واحد سازمانی
- سمت
- وضعیت استخدام
- محل فعالیت
اگر سیستم کنترل دسترسی کاملاً مستقل باشد، ممکن است اپراتور مجبور شود اطلاعات را دوباره وارد کند.
اما در یک پروژه یکپارچه می‌توان ارتباط میان سیستم منابع انسانی و اکسس کنترل را طراحی کرد.
برای مثال:
استخدام کارمند جدید
→ ایجاد هویت
→ تعریف credential
→ تعیین نقش
→ اختصاص سطح دسترسی
→ فعال شدن دسترسی
و در زمان پایان همکاری:
خروج کارمند
→ حذف یا تعلیق credential
→ قطع دسترسی ساختمان
→ قطع دسترسی آسانسور
→ قطع دسترسی پارکینگ
این نوع خودکارسازی در راهکارهای مدیریت هویت و دسترسی فیزیکی Enterprise برای کاهش خطای انسانی و مدیریت چرخه عمر دسترسی استفاده می‌شود.
اکسس کنترل و حضور و غیاب
در برخی پروژه‌ها ممکن است کارفرما بخواهد اطلاعات تردد فقط برای امنیت استفاده نشود و در سامانه‌های دیگری نیز مورد استفاده قرار گیرد.
برای مثال:
ورود کارمند
→ ثبت رویداد در کنترل تردد
→ ارسال اطلاعات به سامانه حضور و غیاب
در چنین پروژه‌ای باید از ابتدا مشخص شود که کدام سیستم مالک اطلاعات است و تبادل اطلاعات چگونه انجام می‌شود.
این موضوع می‌تواند از طریق API، سرویس نرم‌افزاری یا روش‌های ارتباطی مورد توافق پروژه طراحی شود.
بنابراین اگر کارفرما علاوه بر اکسس کنترل، سامانه حضور و غیاب یا نرم‌افزار سازمانی دارد، این موضوع باید در مرحله تحلیل نیازمندی‌ها مطرح شود.
API و اتصال اکسس کنترل به نرم‌افزارهای سازمانی
یکی از مهم‌ترین قابلیت‌ها در پروژه‌های سفارشی، امکان اتصال سیستم کنترل دسترسی به نرم‌افزارهای دیگر است.
برای مثال:
نرم‌افزار سازمان
↔
سامانه مدیریت کاربران
↔
اکسس کنترل
↔
آسانسور و ورودی‌ها
در این معماری، سیستم کنترل دسترسی می‌تواند بخشی از یک اکوسیستم نرم‌افزاری بزرگ‌تر باشد.
در راهکارهای Enterprise امروزی، API برای اتصال سیستم کنترل دسترسی به سامانه‌هایی مانند HR، مدیریت مهمان، نرم‌افزارهای هویتی، حضور و غیاب و حتی سامانه‌های نظارتی استفاده می‌شود.
سامانه تحت وب برای مدیریت اکسس کنترل
در پروژه‌های کوچک ممکن است مدیریت دستگاه با ابزار محلی کاملاً کافی باشد.
اما در یک سازمان بزرگ، مدیر یا اپراتور ممکن است بخواهد از یک رایانه یا مرورگر به سیستم دسترسی داشته باشد.
در این شرایط می‌توان سامانه تحت وب را به‌عنوان بخشی از راهکار طراحی کرد.
برای مثال اپراتور می‌تواند:
- کاربران را مشاهده کند؛
- credential تعریف کند؛
- دسترسی را تغییر دهد؛
- دسترسی را تعلیق کند؛
- credential گمشده را حذف کند؛
- طبقات مجاز را تغییر دهد؛
- گزارش تردد مشاهده کند؛
- وضعیت نقاط کنترل را بررسی کند.
سامانه‌های تحت وب و ابری امروزی نیز دقیقاً با هدف مدیریت متمرکز کاربران، نقاط دسترسی، رویدادها و سیستم‌های مختلف در یک داشبورد توسعه یافته‌اند.
اپلیکیشن موبایل برای مدیریت اکسس کنترل سازمان
در برخی پروژه‌ها، مدیریت فقط از طریق کامپیوتر کافی نیست.
ممکن است مدیر امنیت، مدیر ساختمان یا مسئول مجموعه بخواهد بخشی از عملیات را از طریق تلفن همراه انجام دهد.
برای مثال:
مشاهده رویدادهای اخیر
بررسی وضعیت یک credential
تعلیق دسترسی
فعال‌سازی مجدد
بررسی وضعیت یک ورودی
این قابلیت می‌تواند به‌صورت اپلیکیشن اختصاصی یا از طریق یک سامانه وب واکنش‌گرا طراحی شود.
البته در پروژه‌های حساس، سطح دسترسی خود اپراتورها نیز باید مشخص باشد.
مدیریت اپراتورها و سطح دسترسی مدیران
یک اشتباه مهم در طراحی سیستم‌های سازمانی این است که تصور کنیم فقط کاربران عادی نیاز به سطح دسترسی دارند.
اپراتورهای سیستم نیز باید سطح دسترسی داشته باشند.
برای مثال:
اپراتور پذیرش
فقط مدیریت مهمانان.
مسئول منابع انسانی
مدیریت کارکنان و credentialهای آنها.
مسئول امنیت
مدیریت کامل دسترسی‌ها و گزارش‌ها.
مدیر ارشد
مشاهده گزارش‌ها و تأیید تغییرات حساس.
این تفکیک باعث می‌شود یک اپراتور نتواند خارج از مسئولیت خود تغییرات حساس ایجاد کند.
در سامانه‌های Enterprise، ثبت و ممیزی عملیات مدیریتی نیز بخشی از معماری امنیتی محسوب می‌شود.
ثبت رویدادها و گزارش‌گیری
در پروژه سازمانی فقط «باز شدن در» مهم نیست.
باید بتوان پرسید:
چه کسی؟
کجا؟
چه زمانی؟
با چه credentialی؟
با چه نتیجه‌ای؟
به همین دلیل ثبت رویدادها یکی از بخش‌های مهم سیستم است.
برای مثال:
کاربر ۱۲۵ — ورودی ساختمان A — ساعت ۸:۱۲ — مجاز
یا:
credential شماره ۳۲۱ — آسانسور B — طبقه ۷ — ساعت ۱۴:۲۷ — مجاز
یا:
credential شماره ۴۵۶ — ورودی پارکینگ — ساعت ۱۸:۴۰ — غیرمجاز
گزارش‌ها می‌توانند برای بررسی امنیتی، مدیریت کاربران، تحلیل تردد و در صورت نیاز ممیزی سیستم استفاده شوند.
در سامانه‌های Enterprise، ثبت رویدادهای هویتی، تغییرات مجوز و فعالیت‌های مدیریتی برای ایجاد یک مسیر قابل ممیزی اهمیت ویژه‌ای دارد.
یکپارچه‌سازی دوربین و کنترل دسترسی
در پروژه‌های بزرگ ممکن است کارفرما بخواهد کنترل دسترسی و سیستم نظارت تصویری نیز با یکدیگر ارتباط داشته باشند.
برای مثال:
رویداد ورود یک کاربر
→ ثبت در اکسس کنترل
→ مشخص شدن زمان و محل
→ ارتباط با تصویر دوربین همان نقطه
در این حالت اپراتور امنیت می‌تواند رویدادهای فیزیکی را در کنار اطلاعات تصویری بررسی کند.
البته نوع و سطح این یکپارچه‌سازی باید بر اساس تجهیزات موجود، پروتکل‌ها و نیاز پروژه طراحی شود.
اتصال به پلاک‌خوان و مدیریت خودرو
در پروژه‌هایی که ورود خودرو نیز اهمیت دارد، پلاک خودرو می‌تواند بخشی از اطلاعات هویتی یا مجوز تردد باشد.
برای مثال:
کارمند
→ شماره پرسنلی
→ credential
→ پلاک خودرو
→ مجوز پارکینگ
در زمان ورود خودرو، سیستم می‌تواند پلاک را با اطلاعات ثبت‌شده تطبیق دهد.
در پروژه‌های سازمانی مدرن، اتصال کنترل دسترسی خودرو به سیستم هویت و پارکینگ می‌تواند بخشی از معماری یکپارچه باشد.
نگهبانی و مدیریت ورودی مجتمع
نگهبانی یکی از مهم‌ترین نقاط اجرای سیاست‌های کنترل تردد است.
ممکن است نگهبان نیاز داشته باشد:
- ورود مهمان را ثبت کند؛
- مجوز مهمان را صادر کند؛
- وضعیت مراجعه‌کننده را بررسی کند؛
- دسترسی موقت ایجاد کند؛
- ورود خودرو را کنترل کند؛
- یا یک رویداد امنیتی را ثبت کند.
در چنین شرایطی بهتر است سیستم نگهبانی از سیستم کنترل دسترسی جدا و بدون ارتباط نباشد.
می‌توان برای نگهبان یک پنل مدیریتی متناسب با وظایف او طراحی کرد.
اکسس کنترل سازمانی بدون نیاز به تعویض همه تجهیزات
یکی از نکات مهم در پروژه‌های واقعی این است که کارفرما ممکن است از قبل تجهیزات مختلفی داشته باشد.
مثلاً:
- بخشی از کارت‌خوان‌ها نصب شده‌اند؛
- پنل‌های آسانسور موجود هستند؛
- سیستم پارکینگ قبلاً نصب شده؛
- دوربین‌ها فعال هستند؛
- نرم‌افزار سازمانی وجود دارد.
در این شرایط همیشه لازم نیست تمام سیستم‌ها کنار گذاشته شوند.
در بسیاری از پروژه‌های Enterprise، امکان Integration با زیرساخت‌های موجود یکی از مزیت‌های مهم راهکار محسوب می‌شود.
در طراحی سفارشی نیز می‌توان ابتدا زیرساخت موجود را بررسی کرد و سپس مشخص کرد:
کدام قسمت حفظ شود؟
کدام قسمت توسعه پیدا کند؟
کدام قسمت تعویض شود؟
و:
کدام قسمت باید به سیستم جدید متصل شود؟
این رویکرد می‌تواند هزینه و ریسک مهاجرت را کاهش دهد.
معماری یکپارچه برای یک پروژه بزرگ چگونه می‌تواند باشد؟
فرض کنیم یک سازمان دارای چند ساختمان است.
ساختار کلی می‌تواند به این شکل باشد:
سامانه مدیریت مرکزی
↓
مدیریت کاربران و credentialها
↓
ساختمان A / ساختمان B / ساختمان C
↓
ورودی‌ها + آسانسورها + پارکینگ + فضاهای داخلی
↓
کنترلرها و تجهیزات محلی
در کنار این ساختار:
منابع انسانی
مدیریت مهمان
حضور و غیاب
سامانه نگهبانی
دوربین
می‌توانند بر اساس نیاز پروژه به سامانه مرکزی متصل شوند.
این همان نقطه‌ای است که اکسس کنترل از یک «محصول» به یک راهکار مهندسی‌شده برای مدیریت تردد سازمان تبدیل می‌شود.
آیا برای همه پروژه‌ها سامانه تحت وب لازم است؟
خیر.
این نکته از نظر فروش نیز بسیار مهم است.
نباید برای یک پروژه کوچک، امکاناتی که کاربردی برای آن ندارد تحمیل شود.
برای یک پروژه کوچک ممکن است:
اکسس کنترل + ریموت تنظیمات
کاملاً کافی باشد.
برای پروژه متوسط ممکن است:
اکسس کنترل + گزارش‌گیری + اپلیکیشن
مناسب باشد.
و برای پروژه بزرگ:
سامانه مرکزی + وب + API + چند ساختمان + مدیریت مهمان + پارکینگ + آسانسور
ضروری شود.
بنابراین راهکار باید متناسب با نیاز و بودجه پروژه طراحی شود.
نوین کیا تک؛ از محصول آماده تا طراحی راهکار سازمانی
تجربه پروژه‌های کنترل دسترسی نشان می‌دهد که نیاز مشتریان همیشه یکسان نیست.
گاهی مشتری فقط یک دستگاه اکسس کنترل می‌خواهد.
گاهی به چند خروجی و چند روش شناسایی نیاز دارد.
گاهی لازم است پنل شستی آسانسور همراه با اکسس کنترل طراحی شود.
و گاهی پروژه از یک دستگاه فراتر می‌رود و به یک راهکار شامل:
آسانسور + ورودی + پارکینگ + مهمان + کاربران + گزارش‌گیری + اپلیکیشن یا سامانه تحت وب
نیاز دارد.
در چنین پروژه‌هایی، نوین کیا تک می‌تواند به‌جای محدود کردن پروژه به یک محصول ثابت، ابتدا نیازمندی‌های پروژه را بررسی و سپس راهکار مناسب را پیشنهاد کند.
در صورت نیاز، قابلیت‌های اختصاصی نیز می‌توانند در قالب طراحی و توسعه سفارشی به راهکار اضافه شوند.
یک پروژه سازمانی را از کجا شروع کنیم؟
قبل از انتخاب دستگاه، بهتر است اطلاعات زیر مشخص شود:
- تعداد ساختمان‌ها و بلوک‌ها
- تعداد آسانسورها
- تعداد طبقات
- تعداد کاربران
- تعداد کارکنان
- تعداد پیمانکاران
- تعداد مهمانان
- تعداد ورودی‌ها
- تعداد پارکینگ‌ها
- نوع درب‌ها
- روش‌های شناسایی موردنیاز
- سطح دسترسی کاربران
- نیاز به گزارش‌گیری
- نیاز به اپلیکیشن
- نیاز به سامانه تحت وب
- نرم‌افزارهای موجود
- نیاز به API یا اتصال به سامانه‌های دیگر
- تجهیزات موجود که باید حفظ شوند
- تجهیزات جدید موردنیاز
- سطح امنیت مورد انتظار
- شرایط توسعه آینده پروژه
پس از مشخص شدن این موارد می‌توان معماری مناسبی برای پروژه پیشنهاد داد.
یک پروژه بزرگ لزوماً با یک دستگاه بزرگ حل نمی‌شود
در پروژه‌های سازمانی، گاهی تصور می‌شود باید یک کنترلر بسیار بزرگ خریداری شود که همه کارها را انجام دهد.
در عمل، طراحی صحیح می‌تواند شامل چند لایه باشد.
ممکن است کنترلرهای محلی در نقاط مختلف نصب شوند و مدیریت آنها از طریق یک لایه نرم‌افزاری مرکزی انجام شود.
مزیت چنین معماری‌ای این است که خرابی یا تغییر در یک بخش الزاماً کل پروژه را متوقف نمی‌کند و توسعه آینده نیز می‌تواند ساده‌تر باشد.
به همین دلیل در پروژه‌های بزرگ باید به جای سؤال:
«کدام دستگاه را بخریم؟»
ابتدا پرسید:
«چه معماری‌ای برای این پروژه مناسب است؟»
قابلیت توسعه؛ یک سرمایه برای آینده سازمان
ممکن است سازمان امروز فقط کنترل آسانسور را بخواهد.
اما فردا نیازهای دیگری ایجاد شود:
- پارکینگ
- ورودی جدید
- ساختمان جدید
- کاربران بیشتر
- اپلیکیشن
- گزارش‌گیری
- مدیریت مهمان
- اتصال به منابع انسانی
- پلاک‌خوان
اگر سیستم از ابتدا با نگاه توسعه‌پذیر طراحی شده باشد، اضافه کردن این قابلیت‌ها ساده‌تر خواهد بود.
بنابراین هنگام سفارش یک پروژه سازمانی، فقط نیازهای امروز را نباید دید.
باید پرسید:
این سیستم سه یا پنج سال بعد قرار است چه چیزی را مدیریت کند؟
پروژه سازمانی شما چه ابعادی دارد؟
اگر پروژه شما شامل چند ساختمان، چند آسانسور، پارکینگ، ورودی‌های متعدد، کارکنان، مهمانان، پیمانکاران یا نیاز به سامانه تحت وب و اپلیکیشن است، بهتر است پیش از خرید تجهیزات، ساختار پروژه به‌صورت مهندسی بررسی شود.
نوین کیا تک می‌تواند بر اساس ابعاد پروژه، روش‌های شناسایی، تعداد نقاط کنترل و امکانات موردنیاز، راهکار مناسب را طراحی و در صورت نیاز قابلیت‌های اختصاصی آن را توسعه دهد.
برای بررسی پروژه سازمانی و دریافت پیشنهاد فنی، مشخصات ساختمان‌ها، آسانسورها، پارکینگ و تعداد کاربران را ارسال کنید.
تماس با کارشناسان نوین کیا تک
پرسش‌های متداول درباره یکپارچه‌سازی اکسس کنترل سازمانی
آیا اکسس کنترل آسانسور می‌تواند با سیستم کنترل ورود ساختمان یکپارچه شود؟
بله. در صورت سازگاری زیرساخت و طراحی مناسب، می‌توان کنترل ورود ساختمان و دسترسی آسانسور را در یک معماری یکپارچه قرار داد.
آیا می‌توان از یک کارت برای ورود، پارکینگ و آسانسور استفاده کرد؟
در معماری مناسب، یک credential می‌تواند برای چند نقطه استفاده شود؛ اما مجوز آن در هر نقطه می‌تواند متفاوت باشد.
آیا می‌توان برای مهمان دسترسی موقت تعریف کرد؟
بله. می‌توان دسترسی مهمان را محدود به زمان، محل یا طبقه موردنظر طراحی کرد. سیستم‌های Enterprise نیز Visitor Management را با کنترل دسترسی یکپارچه می‌کنند.
آیا امکان مدیریت پیمانکاران وجود دارد؟
بله. می‌توان برای پیمانکاران credential و سطح دسترسی مشخص تعریف کرد و پس از پایان اعتبار آن را غیرفعال کرد.
آیا امکان اتصال اکسس کنترل به نرم‌افزار سازمانی وجود دارد؟
در پروژه‌های سفارشی، بسته به نرم‌افزار مقصد و امکانات ارتباطی آن، می‌توان API یا روش ارتباطی مناسب را بررسی و طراحی کرد.
آیا حتماً باید همه تجهیزات قبلی سازمان تعویض شوند؟
خیر. ابتدا باید تجهیزات موجود بررسی شود تا مشخص شود کدام قسمت‌ها قابلیت استفاده مجدد یا اتصال به راهکار جدید را دارند.
آیا سامانه تحت وب برای همه پروژه‌ها لازم است؟
خیر. سامانه تحت وب باید بر اساس اندازه، پیچیدگی و نیاز مدیریتی پروژه انتخاب شود.
آیا امکان طراحی اپلیکیشن اختصاصی وجود دارد؟
در پروژه‌های سفارشی می‌توان نیاز به اپلیکیشن را در مرحله طراحی و توسعه بررسی کرد.
آیا می‌توان چند ساختمان را از یک سیستم مدیریت کرد؟
در صورت طراحی معماری مناسب، مدیریت متمرکز چند ساختمان و چند محل امکان‌پذیر است. راهکارهای Enterprise نیز برای مدیریت چندسایتی و متمرکز طراحی می‌شوند.
جمع‌بندی تا اینجا
اکسس کنترل برای پروژه‌های سازمانی زمانی ارزش واقعی خود را نشان می‌دهد که از یک دستگاه مستقل فراتر برود و به بخشی از زیرساخت مدیریت تردد سازمان تبدیل شود.
در چنین پروژه‌ای می‌توان بر اساس نیاز، بخش‌هایی مانند:
ورودی ساختمان
آسانسورها
پارکینگ
مهمانان
پیمانکاران
نگهبانی
کارکنان
گزارش‌گیری
اپلیکیشن
سامانه تحت وب
و حتی نرم‌افزارهای سازمانی دیگر
را در یک معماری منسجم در نظر گرفت.
اما نکته مهم این است که یکپارچه‌سازی نباید صرفاً برای پیچیده‌تر کردن پروژه انجام شود.
هر قابلیت باید یک مسئله واقعی سازمان را حل کند.
به همین دلیل، در نوین کیا تک رویکرد مناسب برای پروژه‌های سازمانی، ابتدا تحلیل نیازمندی و طراحی راهکار و سپس انتخاب یا توسعه تجهیزات و نرم‌افزار است.
در چنین رویکردی، حتی اگر پروژه از یک اکسس کنترل ساده شروع شود، می‌توان معماری آن را به‌گونه‌ای طراحی کرد که در آینده قابلیت توسعه به یک راهکار جامع کنترل تردد را داشته باشد.
یک پروژه سازمانی واقعی چه شکلی است؟
وقتی درباره «اکسس کنترل سازمانی» صحبت می‌کنیم، منظور الزاماً یک سازمان بسیار بزرگ با هزاران کاربر نیست.
ممکن است پروژه‌ای با یک ساختمان، چند آسانسور و چندصد کاربر شروع شود؛ یا سازمانی چندین ساختمان، پارکینگ، ورودی، اتاق‌های حساس و تعداد زیادی کاربر داشته باشد.
تفاوت اصلی در این است که در پروژه سازمانی، اکسس کنترل بخشی از فرآیند مدیریت تردد سازمان است و نه صرفاً یک دستگاه برای باز کردن در.
برای مثال ممکن است یک سازمان نیاز داشته باشد:
- کارکنان به ساختمان وارد شوند؛
- هر کارمند فقط به طبقات مرتبط دسترسی داشته باشد؛
- مدیران دسترسی گسترده‌تری داشته باشند؛
- پیمانکاران دسترسی موقت داشته باشند؛
- مهمانان فقط به محل موردنظر هدایت شوند؛
- پارکینگ نیز مدیریت شود؛
- آسانسورها سطح دسترسی طبقات را اعمال کنند؛
- ورود و خروج ثبت شود؛
- و مدیر امنیت بتواند همه این اطلاعات را مدیریت کند.
در چنین شرایطی، انتخاب یک دستگاه آماده بدون تحلیل کل پروژه می‌تواند تصمیم درستی نباشد.
سناریوی اول: سازمانی با یک ساختمان و چند آسانسور
فرض کنید یک ساختمان اداری چندطبقه دارای چند آسانسور است.
در ساده‌ترین حالت، می‌توان برای کارکنان کارت یا تگ تعریف کرد و هنگام استفاده از آسانسور، فقط طبقات مجاز برای هر کاربر فعال شوند.
برای مثال:
طبقات ۱، ۲ و ۳ → کارمند واحد مالی
طبقات ۱، ۴ و ۵ → کارمند واحد فنی
تمام طبقات → مدیر
فقط طبقه موردنظر → مهمان
در این پروژه ممکن است هنوز نیازی به یک سامانه بسیار پیچیده وجود نداشته باشد.
اما اگر تعداد کاربران زیاد شود یا سازمان به گزارش‌گیری، اپلیکیشن یا ارتباط با سامانه‌های دیگر نیاز پیدا کند، معماری پروژه می‌تواند توسعه پیدا کند.
سناریوی دوم: ساختمان اداری با پارکینگ
در پروژه‌های اداری، کنترل ورود ساختمان و پارکینگ می‌تواند به یکدیگر مرتبط باشد.
فرض کنید یک کارمند مجاز به استفاده از پارکینگ است.
پس از ورود خودرو، او وارد ساختمان می‌شود و سپس از آسانسور استفاده می‌کند.
می‌توان سیاست دسترسی را به‌گونه‌ای طراحی کرد که credential کاربر در بخش‌های مختلف پروژه دارای مجوزهای مشخص باشد.
برای مثال:
مجاز → پارکینگ
مجاز → لابی
مجاز → آسانسور
مجاز → طبقات ۱ تا ۵
غیرمجاز → طبقات مدیریتی
این همان تفاوت میان «داشتن credential» و «داشتن مجوز مناسب» است.
سناریوی سوم: سازمان چند بلوکی
حالا پروژه را بزرگ‌تر کنیم.
سازمان چند ساختمان یا بلوک دارد و هر بلوک چند آسانسور دارد.
در این شرایط دیگر مدیریت جداگانه هر ساختمان می‌تواند برای مدیر امنیت بسیار زمان‌بر باشد.
یک معماری متمرکز می‌تواند اطلاعات کاربران و سیاست‌های دسترسی را در سطح پروژه مدیریت کند و در عین حال برای هر ساختمان، بلوک، آسانسور یا طبقه مجوزهای متفاوت داشته باشد.
در راهکارهای Enterprise چندسایتی نیز هدف دقیقاً ایجاد مدیریت متمرکز سیاست‌های دسترسی و هویت در مجموعه‌های توزیع‌شده است.
سناریوی چهارم: کارکنان، پیمانکاران و مهمانان
فرض کنید یک سازمان علاوه بر کارکنان دائمی، تعداد زیادی پیمانکار و مراجعه‌کننده نیز دارد.
اگر همه این افراد با یک روش و یک سطح دسترسی مدیریت شوند، کنترل سیستم دشوار می‌شود.
بهتر است حداقل سه گروه جداگانه تعریف شوند:
کارکنان
دسترسی متناسب با سمت و محل کار.
پیمانکاران
دسترسی محدود و در صورت نیاز موقت.
مهمانان
دسترسی محدود به محل و زمان مراجعه.
برای سیستم‌های Enterprise، مدیریت چرخه عمر کارکنان، پیمانکاران، فروشندگان و مهمانان یکی از بخش‌های اصلی مدیریت هویت فیزیکی محسوب می‌شود.
سناریوی پنجم: سازمانی که سیستم فعلی دارد اما پاسخگوی نیاز جدید نیست
همیشه پروژه از صفر شروع نمی‌شود.
گاهی سازمان از قبل اکسس کنترل دارد اما به مرور نیازهای جدیدی ایجاد شده است.
مثلاً:
- تعداد کارکنان افزایش یافته؛
- ساختمان جدید اضافه شده؛
- آسانسورهای جدید نصب شده‌اند؛
- پارکینگ توسعه پیدا کرده؛
- نیاز به گزارش‌گیری ایجاد شده؛
- مدیریت مهمان لازم شده؛
- یا سازمان به اپلیکیشن نیاز پیدا کرده است.
در این شرایط اولین راه‌حل الزاماً تعویض کل سیستم نیست.
ابتدا باید بررسی شود که تجهیزات موجود چه قابلیت‌هایی دارند و چه بخش‌هایی امکان توسعه یا اتصال به سیستم جدید را دارند.
در معماری‌های Enterprise نیز یکی از اهداف مهم Integration، ایجاد ارتباط میان سیستم‌های موجود و لایه‌های جدید مدیریت هویت و سیاست دسترسی است.
سناریوی ششم: پروژه‌ای که محصول آماده بازار پاسخگوی آن نیست
گاهی کارفرما یک نیاز کاملاً مشخص دارد.
برای مثال:
«می‌خواهیم یک روش شناسایی خاص برای آسانسور داشته باشیم و همزمان سطح دسترسی کاربران، پارکینگ، مهمان و گزارش‌گیری نیز مدیریت شود.»
یا:
«پنل شستی آسانسور باید دقیقاً مطابق طراحی معماری پروژه ساخته شود و اکسس کنترل نیز داخل همان پنل قرار بگیرد.»
یا:
«سیستم باید با نرم‌افزار فعلی سازمان ارتباط داشته باشد.»
در این شرایط مقایسه چند دستگاه آماده بازار ممکن است مسئله را حل نکند.
چون مسئله اصلی دیگر «انتخاب دستگاه» نیست.
مسئله، طراحی راهکار است.
محصول آماده یا طراحی سفارشی؟
برای انتخاب درست، می‌توان این قاعده ساده را در نظر گرفت:
اگر نیاز شما مشخص و استاندارد است
محصول آماده معمولاً انتخاب اقتصادی‌تر و سریع‌تری است.
اگر نیاز شما ترکیبی است
ابتدا باید مشخص شود آیا می‌توان چند محصول را در کنار هم استفاده کرد یا خیر.
اگر نیاز شما خاص و منحصربه‌فرد است
بهتر است پروژه به‌صورت طراحی و توسعه سفارشی بررسی شود.
این رویکرد باعث می‌شود مشتری برای قابلیت‌هایی که به آنها نیاز ندارد هزینه نکند و در عین حال، پروژه‌های پیچیده نیز به دلیل محدودیت یک محصول آماده متوقف نشوند.
طراحی سفارشی الزاماً به معنی ساخت همه چیز از صفر نیست
این نکته بسیار مهم است.
«سفارشی» به این معنی نیست که تمام تجهیزات پروژه باید از ابتدا ساخته شوند.
ممکن است:
- پنل شستی آماده باشد؛
- کارت‌خوان آماده باشد؛
- بخشی از تجهیزات پارکینگ موجود باشد؛
- کنترلرهای محلی آماده باشند؛
- اما منطق ارتباطی یا نرم‌افزار مدیریت نیاز به توسعه داشته باشد.
یا برعکس، ممکن است خود پنل شستی نیز متناسب با معماری پروژه طراحی شود.
بنابراین یک پروژه سفارشی می‌تواند ترکیبی از:
محصول آماده + تجهیزات اختصاصی + Firmware اختصاصی + نرم‌افزار اختصاصی + Integration
باشد.
طراحی پنل اختصاصی برای پروژه‌های سازمانی
در پروژه‌هایی که تعداد زیادی آسانسور یا ساختمان وجود دارد، ظاهر و ساختار پنل‌ها نیز اهمیت پیدا می‌کند.
ممکن است کارفرما بخواهد:
- پنل‌ها ظاهر یکسان داشته باشند؛
- برند سازمان روی پنل درج شود؛
- کارت‌خوان داخل پنل قرار گیرد؛
- اثر انگشت به پنل اضافه شود؛
- نمایشگر خاصی استفاده شود؛
- کلیدهای لمسی یا فشاری استفاده شوند؛
- پنل توکار یا روکار باشد؛
- یا ابعاد پنل دقیقاً با معماری کابین هماهنگ شود.
در چنین پروژه‌ای، طراحی پنل و سیستم کنترل دسترسی می‌تواند به‌صورت یک راهکار یکپارچه دیده شود.
ترکیب چند روش شناسایی در پروژه‌های سازمانی
ممکن است یک سازمان برای تمام کاربران فقط یک روش شناسایی نخواهد.
برای مثال:
کارت → کارکنان
کارت + اثر انگشت → مدیران
credential موقت → مهمان
ریموت اختصاصی → نگهبان یا لابیمن
روش احراز هویت قوی‌تر → دسترسی‌های خاص
این معماری اجازه می‌دهد هزینه و سطح امنیت برای همه کاربران یکسان نباشد.
یعنی به جای اینکه برای همه کاربران گران‌ترین روش انتخاب شود، روش مناسب برای هر سناریو انتخاب می‌شود.
مدیریت تغییرات کاربران در طول زمان
سازمان ثابت نیست.
کارمندان جابه‌جا می‌شوند.
سمت‌ها تغییر می‌کنند.
پیمانکاران پروژه خود را تمام می‌کنند.
کاربران جدید اضافه می‌شوند.
برخی افراد از سازمان خارج می‌شوند.
به همین دلیل سیستم کنترل دسترسی باید با تغییرات سازمانی هماهنگ باشد.
برای مثال:
استخدام کارمند جدید
→ ایجاد کاربر
→ تعریف credential
→ تعیین سطح دسترسی
تغییر واحد سازمانی
→ تغییر مجوزها
پایان همکاری
→ تعلیق یا حذف دسترسی
این همان مفهوم مدیریت چرخه عمر credential است که در راهکارهای Enterprise اهمیت ویژه‌ای دارد.
وقتی یک credential گم می‌شود چه اتفاقی باید بیفتد؟
در یک سازمان بزرگ، گم شدن یک کارت یا credential اتفاق غیرعادی نیست.
مشکل زمانی ایجاد می‌شود که حذف آن دشوار باشد.
سیستم مناسب باید به مدیر اجازه دهد credential موردنظر را سریعاً غیرفعال یا حذف کند.
در پروژه‌های بزرگ حتی بهتر است این کار بدون نیاز به مراجعه فیزیکی به تک‌تک نقاط کنترل امکان‌پذیر باشد.
هدف این است که:
یک credential گمشده = یک مشکل مدیریتی کوچک
و نه:
یک credential گمشده = اختلال در کل سیستم امنیتی سازمان
آیا تعلیق بهتر از حذف است؟
همیشه نه؛ اما در برخی سناریوها بسیار کاربردی است.
فرض کنید کارمند برای مدتی طولانی در سازمان حضور ندارد.
می‌توان credential او را موقتاً تعلیق کرد.
پس از بازگشت:
فعال‌سازی مجدد
و نیازی به تعریف کامل credential از ابتدا نیست.
در مقابل، وقتی کارمند برای همیشه سازمان را ترک می‌کند، حذف دسترسی می‌تواند انتخاب مناسب‌تری باشد.
بنابراین طراحی سیستم باید بتواند تعلیق و حذف را بر اساس سیاست سازمان از یکدیگر تفکیک کند.
گزارش‌گیری در پروژه‌های سازمانی
هرچه تعداد کاربران و نقاط کنترل بیشتر شود، گزارش‌گیری اهمیت بیشتری پیدا می‌کند.
مدیر امنیت ممکن است بخواهد بداند:
- چه کسی وارد ساختمان شده است؟
- چه کسی به یک طبقه خاص دسترسی پیدا کرده است؟
- چه credentialهایی فعال هستند؟
- چه دسترسی‌هایی تغییر کرده‌اند؟
- چه credentialهایی حذف یا تعلیق شده‌اند؟
- چه تلاش‌های ناموفق برای ورود ثبت شده است؟
در راهکارهای Enterprise، ثبت رویدادها و گزارش‌های قابل ممیزی یکی از اجزای مهم مدیریت فیزیکی هویت و دسترسی است.
چرا گزارش فقط برای امنیت نیست؟
گزارش‌های تردد می‌توانند برای مدیریت عملیات نیز مفید باشند.
برای مثال ممکن است سازمان بخواهد:
- الگوی استفاده از ساختمان را بررسی کند؛
- میزان استفاده از فضاها را بسنجد؛
- تردد پیمانکاران را بررسی کند؛
- سوابق یک رویداد امنیتی را تحلیل کند؛
- یا اطلاعات کنترل تردد را با سیستم‌های دیگر تطبیق دهد.
در نتیجه، داده‌های اکسس کنترل می‌توانند بخشی از اطلاعات عملیاتی سازمان نیز باشند.
از یک پروژه کوچک تا یک راهکار سازمانی قابل توسعه
یکی از مزیت‌های طراحی صحیح این است که پروژه می‌تواند مرحله‌به‌مرحله توسعه پیدا کند.
مثلاً:
مرحله اول
کنترل دسترسی آسانسورها.
مرحله دوم
افزودن ورودی‌های ساختمان.
مرحله سوم
مدیریت پارکینگ.
مرحله چهارم
مدیریت مهمان و پیمانکار.
مرحله پنجم
گزارش‌گیری و سامانه مدیریت.
مرحله ششم
اپلیکیشن یا سامانه تحت وب.
مرحله هفتم
اتصال به نرم‌افزارهای سازمانی.
این رویکرد به سازمان اجازه می‌دهد متناسب با نیاز و بودجه، سیستم را توسعه دهد.
یک پروژه سازمانی خوب باید از امروز برای فردا آماده باشد
هنگام طراحی پروژه بهتر است فقط به تعداد فعلی کاربران توجه نشود.
این سؤال‌ها نیز باید پرسیده شوند:
اگر کاربران دو برابر شدند چه؟
اگر ساختمان جدید اضافه شد چه؟
اگر آسانسور جدید اضافه شد چه؟
اگر پارکینگ توسعه پیدا کرد چه؟
اگر سازمان به اپلیکیشن نیاز پیدا کرد چه؟
اگر نرم‌افزار منابع انسانی تغییر کرد چه؟
اگر روش شناسایی جدیدی لازم شد چه؟
اگر معماری سیستم از ابتدا توسعه‌پذیر باشد، پاسخ به این تغییرات ساده‌تر خواهد بود.
نوین کیا تک برای چه نوع پروژه‌ای مناسب است؟
نوین کیا تک فقط برای پروژه‌ای که یک دستگاه آماده اکسس کنترل نیاز دارد، محدود نمی‌شود.
می‌توان پروژه‌ها را در چند سطح دید:
سطح اول؛ محصول آماده
برای پروژه‌هایی که نیاز استاندارد دارند.
سطح دوم؛ راهکار ترکیبی
برای پروژه‌هایی که به چند روش شناسایی یا چند نوع کنترل نیاز دارند.
سطح سوم؛ پنل و تجهیزات سفارشی
برای پروژه‌هایی که طراحی ظاهری و ساختار سخت‌افزاری خاص دارند.
سطح چهارم؛ توسعه Firmware و منطق اختصاصی
برای نیازهایی که در محصول استاندارد وجود ندارند.
سطح پنجم؛ سامانه نرم‌افزاری و یکپارچه‌سازی
برای پروژه‌هایی که نیاز به اپلیکیشن، سامانه تحت وب یا ارتباط با نرم‌افزارهای دیگر دارند.
در پروژه‌های Enterprise نیز همین تفکیک اهمیت دارد؛ راهکار می‌تواند از یک سیستم کنترل دسترسی شروع شود و در سطح بالاتر به مدیریت متمرکز هویت، سیاست‌ها، workflow و چند سایت توسعه پیدا کند.
چه اطلاعاتی برای بررسی یک پروژه سازمانی لازم است؟
اگر قصد دارید یک پروژه را برای بررسی مهندسی ارسال کنید، بهتر است اطلاعات اولیه زیر را در اختیار تیم طراحی قرار دهید:
- تعداد ساختمان‌ها و بلوک‌ها
- تعداد آسانسورها در هر ساختمان
- تعداد طبقات
- تعداد کاربران
- تعداد کارکنان
- تعداد پیمانکاران و مهمانان
- تعداد ورودی‌ها
- وضعیت پارکینگ
- نوع درب‌ها
- تجهیزات فعلی
- روش شناسایی موردنظر
- سطح دسترسی کاربران
- نیاز به گزارش‌گیری
- نیاز به اپلیکیشن
- نیاز به سامانه تحت وب
- نرم‌افزارهای سازمانی موجود
- نیاز به اتصال API
- نیازهای خاص پروژه
- امکاناتی که در آینده احتمالاً به سیستم اضافه خواهند شد
حتی اگر تمام این اطلاعات در ابتدا آماده نباشد، همین اطلاعات اولیه می‌تواند برای شروع تحلیل پروژه کافی باشد.
مراحل بررسی و طراحی یک پروژه سفارشی
فرآیند مناسب می‌تواند به این شکل باشد:
۱. دریافت نیازمندی‌ها
ابتدا ساختار پروژه و نیازهای کارفرما بررسی می‌شود.
۲. بررسی زیرساخت موجود
تجهیزات، آسانسورها، پنل‌ها، پارکینگ و سیستم‌های نرم‌افزاری موجود بررسی می‌شوند.
۳. تعریف سناریوهای دسترسی
مشخص می‌شود هر گروه کاربری به چه نقاطی و در چه شرایطی دسترسی داشته باشد.
۴. انتخاب فناوری
روش مناسب شناسایی و تجهیزات موردنیاز انتخاب می‌شود.
۵. طراحی معماری
ارتباط میان کنترلرها، پنل‌ها، نرم‌افزار و سایر سیستم‌ها مشخص می‌شود.
۶. توسعه قابلیت‌های اختصاصی
در صورت نیاز، Firmware، نرم‌افزار، پنل یا بخش‌های دیگر توسعه داده می‌شوند.
۷. تست
سناریوهای واقعی پروژه قبل از تحویل بررسی می‌شوند.
۸. اجرا و تحویل
پس از تأیید، سیستم در پروژه اجرا و راه‌اندازی می‌شود.
۹. توسعه آینده
معماری سیستم به‌گونه‌ای در نظر گرفته می‌شود که در صورت نیاز امکان توسعه وجود داشته باشد.
چرا برای پروژه سازمانی نباید فقط قیمت یک دستگاه را مقایسه کرد؟
در یک پروژه کوچک ممکن است قیمت دستگاه یکی از مهم‌ترین معیارها باشد.
اما در پروژه سازمانی، هزینه واقعی فقط قیمت تجهیزات نیست.
باید مواردی مانند:
- طراحی
- نصب
- راه‌اندازی
- نرم‌افزار
- Integration
- آموزش
- پشتیبانی
- توسعه آینده
- نگهداری
- و مدیریت کاربران
نیز در نظر گرفته شود.
گاهی یک دستگاه ارزان‌تر در زمان خرید، به دلیل محدودیت در توسعه و یکپارچه‌سازی، در بلندمدت هزینه بیشتری به سازمان تحمیل می‌کند.
بنابراین در پروژه‌های سازمانی بهتر است هزینه کل راهکار و قابلیت توسعه آینده مقایسه شود، نه فقط قیمت یک کنترلر یا کارت‌خوان.
یک راهکار خوب باید متناسب با پروژه طراحی شود
برای یک ساختمان کوچک، راهکار ساده می‌تواند بهترین راهکار باشد.
برای یک ساختمان اداری چندآسانسوره، سیستم چندخروجی و مدیریت کاربران می‌تواند مناسب باشد.
برای یک مجموعه چندبلوک، معماری متمرکز و چندسایتی اهمیت پیدا می‌کند.
و برای یک سازمان بزرگ، ممکن است نیاز به ترکیب:
اکسس کنترل + آسانسور + پارکینگ + مهمان + پیمانکار + گزارش‌گیری + اپلیکیشن + سامانه تحت وب + Integration
وجود داشته باشد.
پس نمی‌توان یک محصول واحد را برای همه پروژه‌ها بهترین انتخاب دانست.
بهترین راهکار، راهکاری است که متناسب با مسئله واقعی پروژه طراحی شده باشد.
اگر پروژه شما از یک اکسس کنترل معمولی بزرگ‌تر است
اگر پروژه شما فقط به یک کارت‌خوان و چند خروجی محدود نمی‌شود و نیازهایی مانند:
- چند آسانسور
- چند ساختمان یا بلوک
- پارکینگ
- ورودی‌های متعدد
- کارکنان و مدیران
- مهمان و پیمانکار
- گزارش‌گیری
- اپلیکیشن
- سامانه تحت وب
- اتصال به نرم‌افزار سازمان
- طراحی پنل اختصاصی
- یا قابلیت‌های سفارشی
دارد، بهتر است قبل از انتخاب محصول، سناریوی کامل پروژه بررسی شود.
ممکن است بهترین راهکار، یک محصول آماده باشد؛ ممکن است ترکیبی از چند محصول باشد؛ و ممکن است نیاز به طراحی و توسعه اختصاصی داشته باشد.
تشخیص این موضوع باید بعد از تحلیل نیازمندی‌ها انجام شود.
نهایی؛ پروژه خود را برای ما تعریف کنید
اگر برای یک ساختمان اداری، مجموعه چندبلوک، سازمان، مجتمع بزرگ یا پروژه چندآسانسوره به دنبال راهکار کنترل تردد هستید، لازم نیست از ابتدا بدانید دقیقاً چه دستگاهی باید خریداری کنید.
کافی است ساختار پروژه و نیاز خود را توضیح دهید.
تیم فنی نوین کیا تک می‌تواند بر اساس تعداد ساختمان‌ها، آسانسورها، طبقات، کاربران، پارکینگ، روش‌های شناسایی و نیازهای نرم‌افزاری، ساختار مناسب راهکار را بررسی کند.
اگر نیاز پروژه شما با محصولات آماده قابل حل نباشد، امکان طراحی و توسعه سفارشی نیز قابل بررسی است.
برای بررسی پروژه سازمانی و دریافت پیشنهاد فنی، اطلاعات اولیه پروژه خود را برای نوین کیا تک ارسال کنید.
تماس با کارشناسان نوین کیا تک
اکسس کنترل سازمانی؛ یک محصول یا یک راهکار؟
پاسخ به این سؤال به ابعاد پروژه بستگی دارد.
در یک پروژه ساده، ممکن است یک دستگاه اکسس کنترل تمام نیازها را برطرف کند.
اما در یک پروژه سازمانی بزرگ، اکسس کنترل فقط یکی از اجزای سیستم است.
هویت کاربران، credentialها، سطوح دسترسی، آسانسورها، ورودی‌ها، پارکینگ، مهمانان، پیمانکاران، گزارش‌ها و نرم‌افزارهای سازمانی ممکن است همگی بخشی از راهکار باشند.
راهکارهای Enterprise امروزی نیز به سمت همین مدل حرکت کرده‌اند: مدیریت متمرکز هویت و دسترسی، اعمال سیاست‌ها، مدیریت چرخه عمر credential، پشتیبانی از کاربران مختلف و یکپارچه‌سازی سیستم‌های متعدد.
بنابراین در پروژه‌های پیچیده، سؤال درست این نیست که:
«کدام دستگاه اکسس کنترل را بخریم؟»
بلکه سؤال درست این است:
«چه راهکاری می‌تواند نیازهای امروز و توسعه آینده سازمان ما را پوشش دهد؟»
جمع‌بندی نهایی مقاله
اکسس کنترل برای پروژه‌های سازمانی می‌تواند از یک سیستم ساده کنترل طبقات آسانسور تا یک راهکار جامع برای مدیریت تردد چند ساختمان، چند آسانسور، پارکینگ، ورودی‌ها، کارکنان، مهمانان و پیمانکاران گسترش پیدا کند.
در پروژه‌های کوچک، محصول آماده معمولاً انتخاب منطقی است.
اما هرچه تعداد کاربران، ساختمان‌ها، آسانسورها و سیستم‌های مرتبط افزایش پیدا کند، اهمیت معماری، مدیریت متمرکز، گزارش‌گیری، Integration و قابلیت توسعه بیشتر می‌شود.
در پروژه‌های سفارشی نیز لازم نیست همه چیز از صفر ساخته شود. می‌توان از تجهیزات آماده استفاده کرد و فقط قسمت‌هایی را که پروژه به آنها نیاز دارد توسعه داد.
این رویکرد به سازمان اجازه می‌دهد بدون تحمیل هزینه‌های غیرضروری، راهکاری متناسب با نیاز واقعی خود دریافت کند.
نوین کیا تک می‌تواند از مرحله بررسی نیازمندی و طراحی راهکار تا طراحی پنل، توسعه تجهیزات و قابلیت‌های اختصاصی و در صورت نیاز توسعه بخش‌های نرم‌افزاری، پروژه‌های سفارشی کنترل تردد را بررسی کند.
اگر پروژه شما شامل چند آسانسور، چند ساختمان، پارکینگ، ورودی‌های متعدد یا نیازهای خاص سازمانی است، مشخصات پروژه را ارسال کنید تا امکان طراحی یک راهکار متناسب با نیاز شما بررسی شود.
مقالات تخصصی مرتبط
برای آشنایی عمیق‌تر با بخش‌های مختلف کنترل دسترسی آسانسور، مقالات زیر را نیز مطالعه کنید:
مبانی و فناوری
روش‌های شناسایی
کنترل طبقات
مهمان و لابیمن
- ریموت میهمان آسانسور چیست؟
- ریموت لابیمن آسانسور چیست؟
- تفاوت ریموت میهمان و ریموت لابیمن
- مدیریت دسترسی مهمان در ساختمان
مدیریت و امنیت
- حذف تگ گمشده بدون حضور فیزیکی
- گزارش‌گیری تردد آسانسور
- مدیریت شارژ ساختمان و دسترسی آسانسور
- اکسس کنترل دارای اپلیکیشن اندروید
پنل و نصب
- نحوه سیم‌کشی اکسس کنترل آسانسور
- نصب اکسس کنترل پشت پنل شستی
- اکسس کنترل توکار یا روکار؟
- طراحی پنل شستی مجهز به اکسس کنترل
پروژه و سفارشی‌سازی
- کنترل تردد آسانسور برای ساختمان‌های چند واحدی
- اکسس کنترل سفارشی آسانسور
- مدیریت ریموت جک پارکینگ ساختمان
- اکسس کنترل آسانسور برای پارکینگ
- اکسس کنترل برای ساختمان‌های اداری
- اکسس کنترل برای پروژه‌های سازمانی
