اکسس کنترل برای پروژههای سازمانی چیست؟
اکسس کنترل برای پروژههای سازمانی فقط به معنی نصب یک کارتخوان کنار آسانسور یا درب ورودی نیست.
در یک پروژه سازمانی، تعداد کاربران، ساختمانها، آسانسورها، طبقات، ورودیها و سناریوهای دسترسی میتواند بسیار بیشتر از یک ساختمان معمولی باشد. به همین دلیل سیستم کنترل تردد باید متناسب با ساختار سازمان، نقش کاربران، نقاط کنترل و سیاستهای امنیتی مجموعه طراحی شود.
ممکن است یک پروژه سازمانی شامل موارد زیر باشد:
- یک ساختمان اداری با چند آسانسور
- چند ساختمان در یک مجموعه
- چند بلوک ساختمانی
- چند طبقه پارکینگ
- ورودی اصلی مجموعه
- ورودیهای فرعی
- اتاقهای حساس و محدود
- واحدهای اداری یا سازمانی مختلف
- کارکنان با سطح دسترسی متفاوت
- مدیران و مسئولان ارشد
- نیروهای خدماتی و پیمانکاران
- مهمانان و مراجعهکنندگان
- نگهبانی و حراست
در چنین پروژهای، سؤال اصلی دیگر این نیست که «کدام اکسس کنترل را بخریم؟»
سؤال اصلی این است:
«چگونه یک معماری کنترل تردد طراحی کنیم که با ساختار واقعی سازمان هماهنگ باشد؟»
در راهکارهای سازمانی مدرن نیز معمولاً دسترسی کاربران بر اساس نقش، محل، زمان و سطح مجوز تعریف میشود و سیستم باید بتواند از یک سایت کوچک تا مجموعههای چندسایتی توسعه پیدا کند.
چرا اکسس کنترل سازمانی با اکسس کنترل یک ساختمان معمولی متفاوت است؟
در یک ساختمان کوچک ممکن است چند ده کاربر داشته باشیم و همه آنها تقریباً شرایط دسترسی مشابهی داشته باشند.
اما در یک مجموعه سازمانی ممکن است صدها یا هزاران کاربر وجود داشته باشند که هرکدام سطح دسترسی متفاوتی دارند.
برای مثال:
| گروه کاربری | آسانسور | طبقات | پارکینگ | ورودیهای خاص |
| کارکنان عادی | مجاز | طبقات محل کار | مجاز | محدود |
| مدیران | مجاز | گسترده | مجاز | گسترده |
| حراست | مجاز | گسترده | مجاز | گسترده |
| خدمات | محدود | مشخص | محدود | مشخص |
| پیمانکار | محدود | مشخص | در صورت نیاز | زماندار |
| مهمان | محدود | طبقه مقصد | در صورت نیاز | محدود |
بنابراین در پروژه سازمانی، هویت کاربر به تنهایی کافی نیست؛ سیستم باید بداند این کاربر چه نقشی دارد و به کدام بخشهای مجموعه مجاز است.
اکسس کنترل سازمانی از کجا شروع میشود؟
یک اشتباه رایج این است که تصور کنیم پروژه سازمانی حتماً باید از ابتدا یک سامانه بسیار بزرگ و پیچیده باشد.
در واقع یک پروژه سازمانی میتواند از یک نقطه مشخص شروع شود.
برای مثال:
یک ساختمان → یک آسانسور → چند طبقه → کارت 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 خاص
در پروژههای بزرگتر، همین توسعه میتواند به:
کنترل چند ساختمان + آسانسور + پارکینگ + کاربران + مهمان + گزارشگیری + سامانه تحت وب یا اپلیکیشن
تبدیل شود.
بنابراین بهتر است پروژه از ابتدا با نگاه معماری توسعهپذیر بررسی شود.
یک راهکار سازمانی خوب باید قابل توسعه باشد
ممکن است سازمان امروز ۳ ساختمان داشته باشد و چند سال بعد ساختمانهای جدیدی به مجموعه اضافه شوند.
اگر معماری سیستم از ابتدا توسعهپذیر باشد، اضافه کردن ساختمانها و نقاط کنترل سادهتر خواهد بود.
به همین دلیل در مرحله طراحی باید پرسید:
اگر تعداد کاربران دو برابر شد چه میشود؟
اگر ساختمان جدید اضافه شد چه میشود؟
اگر آسانسور جدید اضافه شد چه میشود؟
اگر سازمان به اپلیکیشن نیاز پیدا کرد چه میشود؟
اگر پارکینگ جدید اضافه شد چه میشود؟
پاسخ به این سؤالها بخشی از مهندسی پروژه است، نه یک موضوع فرعی.
از کنترل یک آسانسور تا مدیریت یک مجموعه سازمانی
اکسس کنترل سازمانی میتواند در مقیاسهای بسیار متفاوت اجرا شود.
مقیاس کوچک
یک ساختمان، یک آسانسور، چند ده کاربر.
مقیاس متوسط
یک مجموعه، چند آسانسور، پارکینگ و صدها کاربر.
مقیاس بزرگ
چند بلوک، تعداد زیادی آسانسور، پارکینگ مشترک، ورودیهای متعدد و هزاران کاربر.
مقیاس سازمانی
چند سایت، کاربران متعدد، سطوح دسترسی مختلف، سامانه مدیریت، گزارشگیری و نیاز به یکپارچهسازی.
نکته مهم این است که روش طراحی باید متناسب با مقیاس پروژه تغییر کند.
روش شناسایی مناسب پروژه شما چیست؟
اگر بین کارت، تگ، اثر انگشت، رمز، ریموت، موبایل یا یک راهکار ترکیبی مردد هستید، بهتر است ابتدا ساختار پروژه بررسی شود.
نوین کیا تک میتواند بر اساس تعداد کاربران، تعداد آسانسورها، طبقات، ساختمانها، پارکینگ، نوع کاربران و سطح امنیت موردنیاز، روش شناسایی مناسب را پیشنهاد دهد.
جمعبندی تا اینجا
در پروژه سازمانی، انتخاب اکسس کنترل از انتخاب یک کارتخوان شروع نمیشود؛ از تعریف هویت و سیاست دسترسی شروع میشود.
کارت، تگ، اثر انگشت، رمز، ریموت یا موبایل فقط ابزارهای شناسایی هستند.
آنچه یک سیستم حرفهای را میسازد، این است که بتوان مشخص کرد:
چه کسی؟
کجا؟
در چه زمانی؟
با چه روشی؟
با چه سطح دسترسی؟
و مهمتر از آن:
اگر شرایط کاربر تغییر کرد، چگونه دسترسی او را تغییر دهیم؟
در یک پروژه سازمانی حرفهای، 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 نیز برای مدیریت چندسایتی و متمرکز طراحی میشوند.
جمعبندی تا اینجا
اکسس کنترل برای پروژههای سازمانی زمانی ارزش واقعی خود را نشان میدهد که از یک دستگاه مستقل فراتر برود و به بخشی از زیرساخت مدیریت تردد سازمان تبدیل شود.
در چنین پروژهای میتوان بر اساس نیاز، بخشهایی مانند:
ورودی ساختمان
آسانسورها
پارکینگ
مهمانان
پیمانکاران
نگهبانی
کارکنان
گزارشگیری
اپلیکیشن
سامانه تحت وب
و حتی نرمافزارهای سازمانی دیگر
را در یک معماری منسجم در نظر گرفت.
اما نکته مهم این است که یکپارچهسازی نباید صرفاً برای پیچیدهتر کردن پروژه انجام شود.
هر قابلیت باید یک مسئله واقعی سازمان را حل کند.
به همین دلیل، در نوین کیا تک رویکرد مناسب برای پروژههای سازمانی، ابتدا تحلیل نیازمندی و طراحی راهکار و سپس انتخاب یا توسعه تجهیزات و نرمافزار است.
در چنین رویکردی، حتی اگر پروژه از یک اکسس کنترل ساده شروع شود، میتوان معماری آن را بهگونهای طراحی کرد که در آینده قابلیت توسعه به یک راهکار جامع کنترل تردد را داشته باشد.
