اکسس کنترل برای پروژههای سازمانی چیست؟
اکسس کنترل برای پروژههای سازمانی فقط به معنی نصب یک کارتخوان کنار آسانسور یا درب ورودی نیست.
در یک پروژه سازمانی، تعداد کاربران، ساختمانها، آسانسورها، طبقات، ورودیها و سناریوهای دسترسی میتواند بسیار بیشتر از یک ساختمان معمولی باشد. به همین دلیل سیستم کنترل تردد باید متناسب با ساختار سازمان، نقش کاربران، نقاط کنترل و سیاستهای امنیتی مجموعه طراحی شود.
ممکن است یک پروژه سازمانی شامل موارد زیر باشد:
- یک ساختمان اداری با چند آسانسور
- چند ساختمان در یک مجموعه
- چند بلوک ساختمانی
- چند طبقه پارکینگ
- ورودی اصلی مجموعه
- ورودیهای فرعی
- اتاقهای حساس و محدود
- واحدهای اداری یا سازمانی مختلف
- کارکنان با سطح دسترسی متفاوت
- مدیران و مسئولان ارشد
- نیروهای خدماتی و پیمانکاران
- مهمانان و مراجعهکنندگان
- نگهبانی و حراست
در چنین پروژهای، سؤال اصلی دیگر این نیست که «کدام اکسس کنترل را بخریم؟»
سؤال اصلی این است:
«چگونه یک معماری کنترل تردد طراحی کنیم که با ساختار واقعی سازمان هماهنگ باشد؟»
در راهکارهای سازمانی مدرن نیز معمولاً دسترسی کاربران بر اساس نقش، محل، زمان و سطح مجوز تعریف میشود و سیستم باید بتواند از یک سایت کوچک تا مجموعههای چندسایتی توسعه پیدا کند.
چرا اکسس کنترل سازمانی با اکسس کنترل یک ساختمان معمولی متفاوت است؟
در یک ساختمان کوچک ممکن است چند ده کاربر داشته باشیم و همه آنها تقریباً شرایط دسترسی مشابهی داشته باشند.
اما در یک مجموعه سازمانی ممکن است صدها یا هزاران کاربر وجود داشته باشند که هرکدام سطح دسترسی متفاوتی دارند.
برای مثال:
| گروه کاربری | آسانسور | طبقات | پارکینگ | ورودیهای خاص |
| کارکنان عادی | مجاز | طبقات محل کار | مجاز | محدود |
| مدیران | مجاز | گسترده | مجاز | گسترده |
| حراست | مجاز | گسترده | مجاز | گسترده |
| خدمات | محدود | مشخص | محدود | مشخص |
| پیمانکار | محدود | مشخص | در صورت نیاز | زماندار |
| مهمان | محدود | طبقه مقصد | در صورت نیاز | محدود |
بنابراین در پروژه سازمانی، هویت کاربر به تنهایی کافی نیست؛ سیستم باید بداند این کاربر چه نقشی دارد و به کدام بخشهای مجموعه مجاز است.
اکسس کنترل سازمانی از کجا شروع میشود؟
یک اشتباه رایج این است که تصور کنیم پروژه سازمانی حتماً باید از ابتدا یک سامانه بسیار بزرگ و پیچیده باشد.
در واقع یک پروژه سازمانی میتواند از یک نقطه مشخص شروع شود.
برای مثال:
یک ساختمان → یک آسانسور → چند طبقه → کارت RFID
اگر نیاز مجموعه افزایش پیدا کند، معماری سیستم میتواند توسعه پیدا کند:
چند آسانسور → چند ساختمان → پارکینگ → ورودیها → کاربران متعدد → گزارشگیری → اپلیکیشن → سامانه تحت وب
این نگاه مرحلهای اهمیت زیادی دارد؛ زیرا ممکن است سازمان امروز فقط به کنترل آسانسور نیاز داشته باشد، اما در آینده کنترل سایر نقاط نیز به پروژه اضافه شود.
بنابراین هنگام انتخاب سیستم، فقط امکانات فعلی را نباید دید.
باید پرسید:
آیا این راهکار قابلیت توسعه متناسب با آینده سازمان را دارد؟
کنترل تردد آسانسور در پروژههای سازمانی
آسانسور یکی از مهمترین نقاط کنترل دسترسی در یک ساختمان سازمانی است.
اگر ورودی ساختمان با کارت کنترل شود اما پس از ورود، فرد بتواند بدون محدودیت هر طبقهای را از داخل آسانسور انتخاب کند، کنترل ورودی بهتنهایی نمیتواند دسترسی طبقات را مدیریت کند.
به همین دلیل در پروژههای سازمانی، کنترل دسترسی آسانسور میتواند بهصورت سطح طبقه تعریف شود.
برای مثال:
این مدل کنترل طبقهای یکی از قابلیتهای مهم سیستمهای کنترل دسترسی آسانسور در پروژههای چندمستأجره و سازمانی است.
وقتی یک سازمان چند آسانسور دارد
در ساختمانهای سازمانی بزرگ ممکن است چند آسانسور در کنار یکدیگر فعالیت کنند.
در این شرایط باید مشخص شود که:
- کدام کاربران از کدام آسانسورها استفاده میکنند؟
- آیا تمام آسانسورها دسترسی یکسان دارند؟
- آیا یک کارت باید روی چند آسانسور فعال باشد؟
- آیا برخی آسانسورها مخصوص کارکنان هستند؟
- آیا آسانسورهای خاصی برای مدیران یا بخشهای امنیتی وجود دارند؟
- آیا دسترسی طبقات در تمام آسانسورها یکسان است؟
برای مثال ممکن است یک کاربر اجازه داشته باشد از سه آسانسور یک ساختمان استفاده کند، اما فقط طبقات ۲، ۳ و ۴ برای او مجاز باشد.
در مقابل، مدیر ساختمان ممکن است روی تمام آسانسورها و تمام طبقات دسترسی داشته باشد.
پس در پروژههای چندآسانسوره، تعداد آسانسورها بخشی از معماری سیستم کنترل تردد است، نه صرفاً تعداد کارتخوانها.
اکسس کنترل برای مجموعههای چندساختمانی
پروژه سازمانی ممکن است به یک ساختمان محدود نباشد.
برای مثال یک سازمان ممکن است:
- ساختمان اداری مرکزی
- ساختمان مدیریت
- ساختمان پشتیبانی
- ساختمان خدمات
- مرکز آموزش
- پارکینگ مرکزی
- ساختمانهای عملیاتی
داشته باشد.
در این حالت، مدیریت دسترسی باید بتواند بین ساختمانها تفاوت قائل شود.
ممکن است یک کارمند فقط به ساختمان محل فعالیت خود دسترسی داشته باشد، در حالی که مدیر یا مسئول حراست به چند ساختمان مجاز باشد.
در سامانههای سازمانی مدرن، مدیریت چند سایت و تعریف سیاستهای دسترسی برای ساختمانها و مکانهای مختلف یکی از ویژگیهای مهم معماری Enterprise محسوب میشود.
یک کارت میتواند برای چند نقطه از سازمان استفاده شود؟
در معماری مناسب، میتوان یک credential را برای یک کاربر تعریف کرد و سپس سطح دسترسی او را در نقاط مختلف مشخص کرد.
برای مثال:
کارت کارمند → ورودی اصلی + آسانسور ساختمان A + پارکینگ
اما همین کارت ممکن است برای ساختمان B مجوز نداشته باشد.
یا:
کارت مدیر → ورودی اصلی + ساختمان A + ساختمان B + پارکینگ + طبقات مدیریتی
این ساختار باعث میشود سازمان مجبور نباشد برای هر نقطه یک سیستم مستقل و جداگانه برای کاربران ایجاد کند.
کنترل دسترسی بر اساس نقش سازمانی
یکی از مهمترین تفاوتهای پروژه سازمانی، وجود گروهها و نقشهای مختلف است.
به جای اینکه برای تکتک افراد بهصورت جداگانه مجوز تعریف شود، میتوان ساختار دسترسی را بر اساس گروه طراحی کرد.
برای مثال:
گروه مدیریت
دسترسی گسترده به ساختمانها و طبقات مدیریتی.
گروه کارکنان
دسترسی به ساختمان و طبقات محل فعالیت.
گروه حراست
دسترسی گسترده برای انجام وظایف امنیتی.
گروه خدمات
دسترسی محدود به بخشهای موردنیاز.
گروه پیمانکار
دسترسی محدود و در صورت نیاز زماندار.
گروه مهمان
دسترسی موقت و محدود.
این روش مدیریت را سادهتر میکند؛ زیرا با تغییر جایگاه یک کاربر، میتوان گروه یا سطح دسترسی او را تغییر داد.
اکسس کنترل سازمانی و مدیریت زمان دسترسی
در پروژههای سازمانی فقط مکان اهمیت ندارد؛ زمان دسترسی نیز اهمیت دارد.
برای مثال:
کارمند عادی:
شنبه تا چهارشنبه — ساعات اداری
نیروی نگهبانی:
۲۴ ساعته
پیمانکار:
فقط دوشنبه — ساعت ۹ تا ۱۳
مهمان:
فقط در بازه زمانی مشخص
مدیر:
بدون محدودیت یا با محدودیت کمتر
در سیستمهایی که زمانبندی دسترسی را پشتیبانی میکنند، میتوان مجوز را همزمان بر اساس کاربر، محل و زمان تعریف کرد. این مدل در راهکارهای سازمانی و کنترل آسانسور مدرن نیز مورد استفاده قرار میگیرد.
کنترل دسترسی مهمان در پروژههای سازمانی
مراجعهکنندگان یکی از مهمترین گروههای کاربری در سازمانها هستند.
مهمان ممکن است برای ملاقات با:
- مدیر
- واحد مالی
- واحد منابع انسانی
- واحد فنی
- واحد فروش
- واحد حقوقی
وارد سازمان شود.
اما این فرد نباید الزاماً به تمام ساختمان و طبقات دسترسی داشته باشد.
برای مثال:
مهمان → ورودی اصلی → طبقه ۵
پس از پایان مراجعه نیز دسترسی او باید پایان پیدا کند.
در سیستمهای پیشرفتهتر، میتوان دسترسی مهمان را بهصورت موقت یا زماندار تعریف کرد و سوابق ورود و خروج را نیز در اختیار مدیریت قرار داد. راهکارهای Enterprise فعلی نیز visitor management را در کنار access control و audit trail قرار میدهند.
کنترل دسترسی پیمانکاران و نیروهای خدماتی
در بسیاری از سازمانها، پیمانکاران و نیروهای خدماتی دائماً در حال رفتوآمد هستند.
برای مثال:
- شرکت تأسیسات
- شرکت نظافت
- پیمانکار آسانسور
- پیمانکار شبکه
- شرکت نگهداری دوربین
- تعمیرکار تجهیزات
- پیمانکار ساختمانی
این افراد معمولاً نباید همان سطح دسترسی کارکنان سازمان را داشته باشند.
میتوان برای آنها یک سطح دسترسی محدود تعریف کرد.
مثلاً:
پیمانکار شبکه → اتاق سرور + طبقه ۳
یا:
تکنسین آسانسور → موتورخانه + محلهای فنی موردنیاز
در راهکارهای Enterprise، مدیریت پیمانکار و دسترسی محدودمدت یکی از سناریوهای مهم کنترل دسترسی محسوب میشود.
وقتی کارمند سازمان تغییر سمت میدهد
در سازمانها تغییرات نیروی انسانی دائمی است.
یک کارمند ممکن است:
- به واحد دیگری منتقل شود؛
- ارتقا پیدا کند؛
- مسئولیت جدید بگیرد؛
- از سازمان خارج شود؛
- مدتی مأمور شود؛
- به ساختمان دیگری منتقل شود.
اگر سیستم کنترل تردد بهصورت اصولی طراحی شده باشد، تغییر سطح دسترسی کاربر نباید باعث تغییر تنظیمات سایر کاربران شود.
برای مثال:
کارمند مالی → انتقال به مدیریت
دسترسی او میتواند از:
طبقات ۲ و ۳
به:
طبقات ۲، ۳، ۷ و ۸
تغییر کند.
این همان جایی است که اهمیت مدیریت ساختاریافته کاربران و گروههای دسترسی مشخص میشود.
حذف یا غیرفعال کردن کارت کارمند
اگر کارت یک کارمند گم شود یا همکاری او با سازمان پایان پیدا کند، باید امکان غیرفعال کردن credential وجود داشته باشد.
این موضوع در یک سازمان بزرگ اهمیت بسیار بیشتری دارد؛ زیرا تعداد کارتها و کاربران زیاد است.
در یک سیستم مناسب:
کاربر حذف یا غیرفعال میشود → دسترسی او قطع میشود → سایر کاربران بدون تغییر باقی میمانند.
در پروژههای بزرگتر، حتی بهتر است سوابق تغییرات مدیریتی نیز قابل ثبت و پیگیری باشند.
اکسس کنترل سازمانی فقط کارت RFID نیست
کارت و تگ RFID یکی از روشهای متداول شناسایی هستند، اما در یک پروژه سازمانی ممکن است روشهای دیگری نیز موردنیاز باشد.
بسته به سطح امنیت و نوع پروژه میتوان از روشهایی مانند:
- کارت RFID
- تگ RFID
- اثر انگشت
- رمز
- ریموت
- credential موبایلی
- روشهای ترکیبی
استفاده کرد.
برای مثال ممکن است:
کارکنان → کارت
اتاق حساس → اثر انگشت
مهمان → دسترسی موقت
و در یک پروژه سفارشی، ترکیبی از چند روش شناسایی در کنار یکدیگر قرار گیرد.
بنابراین انتخاب روش شناسایی باید بر اساس سطح امنیت، تعداد کاربران، نوع کاربری و سناریوی واقعی سازمان انجام شود.
چرا در پروژه سازمانی گاهی یک اکسس کنترل آماده کافی نیست؟
محصول آماده زمانی بهترین انتخاب است که نیاز پروژه با امکانات آن مطابقت داشته باشد.
اما ممکن است سازمان نیازهایی داشته باشد که یک محصول استاندارد پاسخگوی آنها نباشد.
برای مثال:
- تعداد خروجی خاص
- چند روش شناسایی همزمان
- چند آسانسور
- چند ساختمان
- مدیریت پارکینگ
- اپلیکیشن اختصاصی
- سامانه تحت وب
- گزارشگیری خاص
- اتصال به سیستمهای موجود
- پنل شستی اختصاصی
- ساختار دسترسی مخصوص سازمان
در این شرایط، موضوع از انتخاب محصول وارد حوزه طراحی راهکار میشود.
نوین کیا تک نیز در پروژههای خاص میتواند بهجای محدود کردن کارفرما به یک محصول آماده، نیاز پروژه را بررسی کرده و قابلیتهای موردنیاز را بهعنوان یک پروژه طراحی و توسعه سفارشی تعریف کند.
از یک دستگاه ساده تا یک پلتفرم سازمانی
یکی از مزیتهای مهم در طراحی پروژههای سازمانی این است که میتوان سیستم را متناسب با اندازه پروژه تعریف کرد.
برای یک پروژه کوچک ممکن است:
اکسس کنترل + ریموت تنظیمات
کاملاً کافی باشد.
برای پروژهای بزرگتر میتوان:
اکسس کنترل چندخروجی + کارت + اثر انگشت + ریموت
را در نظر گرفت.
و در پروژههای پیچیدهتر میتوان قابلیتهایی مانند:
اپلیکیشن اندروید + مدیریت تحت وب + گزارشگیری + مدیریت چند ساختمان
را به معماری پروژه اضافه کرد.
در بازار 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 باید از زمان تعریف تا تغییر، تعلیق و حذف قابل مدیریت باشد و در صورت نیاز بتوان این مدیریت را در سطح چند ساختمان و چند نقطه کنترل انجام داد.
