کنترل دسترسی در رایانه
در امنیت رایانه‌ای، کنترل دسترسی عمومی شامل، شناسایی، مجوزدهی، احرازهویت، تأیید دسترسی، و می‌باشد. یک تعریف محدودتر از کنترل دسترسی فقط شامل تأیید دسترسی است، که در آن سامانه تصمیم می‌گیرد تا درخواست دسترسی را از یک فاعل از قبل احرازهویت شده، اعطا کند یا رد کند. سامانه این کار را براساس آنکه فاعل مجوز دسترسی به چه چیز را دارد، انجام می‌دهد. معمولاً احرازهویت و کنترل دسترسی در یک عملیات منفرد ترکیب می‌شوند، که در نتیجه آن عملیات، دسترسی بر اساس یک احرازهویت موفق، یا براساس توکن دسترسی بی‌نام، تأیید می‌شود. روش‌های احرازهویت و توکن شامل گذرواژه، اسکن زیستی، کلیدهای فیزیکی، کلیدها و وسایل الکترونیکی، مسیرهای پنهان، مانع اجتماعی، و نظارت توسط انسان‌ها و سامانه‌های خودکار می‌شود.
در هر مدل کنترل دسترسی، «فاعل» همان موجودیتی است که می‌تواند روی سامانه عملی انجام دهد، و «مفعول» موجودیتی است که نمایش‌دهنده منابعی است که دسترسی به آنها احتمالاً نیاز است تا کنترل گردد ( را ببینید). هم فاعل و هم مفعول را باید موجودیت نرم‌افزاری درنظر گرفت، و نه کاربر انسانی: یعنی هر کاربر انسانی فقط توسط موجودیت‌های نرم‌افزاری که کنترل می‌کنند، می‌توانند روی سامانه تأثیر بگذارند.
اگرچه بعضی از سامانه‌ها فاعل را با شناسه کاربری (user ID) معادل می‌دانند، که در نتیجه آن همه پردازه‌های شروع شده توسط یک کاربر به صورت پیش‌فرض مجوزهای مشابهی دارند، این مرحله کنترل، به اندازه ای خوش دانه نیست که بتواند اصل کمینه‌سازی مجوزها را برآورده سازد، و می‌تواند مسئول شیوع بدافزار در این سامانه‌ها درنظر گرفته شود (ناامنی رایانه‌ای را ببینید).
در بعضی از مدل‌ها، مثل ، هر موجودیت نرم‌افزاری می‌تواند به صورت بالقوه هم به صورت فاعل و هم به صورت مفعول عمل کند.
انواع مدل‌های کنترل دسترسی، تا سال ۲۰۱۴، در یکی از این دو کلاس قرار می‌گیرفتند: آن‌هایی که براساس هستند، و آن‌هایی که بر اساس لیست کنترل دسترسی هستند (ACL).
هر دو این روش‌های مبتنی بر توانمندی و مبتنی بر ACL سازوکارهایی در رابطه با اعطای حق دسترسی به همه اعضای یک گروه از فاعل‌ها ارائه می‌دهند (که معمولاً خود گروه به صورت یک فاعل مدل می‌شود).
سامانه‌های کنترل دسترسی این خدمات اساسی را ارائه می‌دهند: مجوزدهی، شناسایی و احرازهویت (I&A)، تأیید دسترسی، و حسابرسی؛ که در آن:
مجوزدهی یعنی عمل تعریف حق دسترسی به فاعل‌ها. یک سیاست مجوزدهی، عملیاتی را که فاعل‌ها اجازه اجرای آن‌ها را در یک سامانه دارند، را تعیین می‌کند.
سیستم‌عامل‌های جدید، سیاست‌های مجوزدهی را به صورت مجموعه‌های «صوری» از مجوزها پیاده‌سازی می‌کنند، که این مجوزها انواع یا افزونه‌های سه نوع اصلی دسترسی هستند:
این حقوق و مجوزها در سامانه‌های مبتنی بر (DAC) و کنترل دسترسی اجباری (MAC) به صورت متفاوتی پیاده‌سازی می‌شوند.
شناسایی و احرازهویت (I&A) همان فرایند «تصدیق پیوند» یک هویت به موجودیتی است که دربارهٔ هویت ادعایی را مطرح می‌کند. فرایند I&A فرض می‌کند که یک تصدیق اولیه از هویت وجود دارد، که معمولاً به آن «اثبات هویت» گفته می‌شود. انواع متنوعی از اثبات هویت وجود دارد، که از تصدیق بین فردی توسط شناسایی از طریق حکومت، تا روش‌های بدون نام، که به ادعاکننده امکان بی‌نام بودن را می‌دهد، را شامل می‌شود. روش استفاده شده برای اثبات هویت و تصدیق باید «سطح اطمینانی» متناسب با استفاده مورد انتظار هویت در سامانه ارائه کنند. در ادامه، موجودیت، «هویت» را همراه با احرازهویت کننده به عنوان روش تصدیق اعلام می‌کند. تنها نیازمندی برای شناسانه آن است که باید در دامنه امنیتی اش یکتا باشد.
احرازهویت‌کننده‌ها معمولاً بر اساس حداقل یکی از این چهار فاکتور هستند:
تأیید دسترسی، همان «تابعی است که در مدت بهره‌برداری دسترسی را اعطا یا رد می‌کند».
در مدت تاییدکردن دسترسی، سامانه نمایش صوری «سیاست مجوزدهی» را با «درخواست دسترسی» مقایسه می‌کند، تا تعیین کند که آیا درخواست باید اعطا یا رد گردد. بعلاوه ارزیابی دسترسی می‌تواند به صورت برخط/در آینده انجام شود.
حسابرسی از بعضی مولفه سامانه مثل دنباله‌های حسابرسی (رکوردها) و لاگ‌ها استفاده می‌کند تا یک فاعل را به عمل‌هایش مرتبط سازد. اطلاعات ذخیره شده باید برای نگاشت فاعل به کاربر کنترل شده کافی باشد. «دنباله حسابرسی» و «لاگ‌ها» برای این موارد مهم اند:
اگر کسی نیست که به صورت مرتب لاگ‌هایتان را بازبینی کند، و آن‌ها به صورت امن و سازگار نگهداشته نشده باشند، ممکن است به عنوان یک مدرک پذیرفته نشوند.
بیشتر سامانه‌ها می‌توانند گزارش‌های خودکار تولید کنند، این کار براساس ملاک‌ها یا آستانه‌های از قبل تعریف شده و معین انجام می‌شود، که مرحله چیدن (Clipping level) نامیده می‌شود. برای مثال، یک مرحله چیدن را می‌توان تنظیم کرد تا گزارشی را در صورت وقوع این موارد تولید کند:
این گزارش‌ها به مدیر سامانه یا مدیر امنیتی کمک می‌کند تا به صورت ساده‌تری تلاش‌های نفوذ ممکن را شناسایی کند.
تعریف مرحله چیدن: توانایی یک دیسک برای نگهداری از ویژگی‌های مغناطیسی و نگهداری از محتوایش. بازه سطح بالا برابر ۶۵ تا ۷۰ درصد است و کیفیت پایین، کمتر از ۵۵ درصد است.
مدل‌های کنترل دسترسی را گاهی به صورت اختیاری و غیراختیاری رده‌بندی می‌کنند. سه مدل شناخته شده‌تر شامل: کنترل دسترسی اختیاری (DAC)، کنترل دسترسی اجباری (MAC)، و کنترل دسترسی مبتنی بر نقش (RBAC) می‌باشد. MAC غیر اختیاری است.
(DAC) سیاستی است که توسط مالک یک مفعول تعیین می‌گردد. مالک تعیین می‌کند که چه کسی اجازه دسترسی به مفعول را دارد، و نیز او چه مجوزهایی دارد.
دو مفهوم مهم در DAC این موارد هستند:
کنترل‌های دسترسی در سامانه‌های کنترل دسترسی یا مبتنی بر ACL می‌تواند اختیاری باشد. (در سامانه مرتبط با توانمندی، مفهوم صریح «مالک» وجود ندارد، بلکه سازنده یک مفعول دارای درجه کنترل مشابهی روی سیاست دسترسی اش است).
کنترل دسترسی اجباری به این موضوع اشاره دارد که فقط و فقط در صورتی اجازه دسترسی به یک مفعول داده شود که قواعدی موجود باشد که به یک کاربر خاص اجازه دسترسی به منبع را بدهد. مدیریت این موضوع مشکل است، اما موقعی که برای محافظت از اطلاعات بسیار حساس استفاده می‌شود، استفاده از آن موجه است. مثال‌های این موضوع شامل اطلاعات نظامی و حکومتی خاص است. مدیریت (روی آنچه لازم است) موقعی ساده است که اطلاعات را بتوان به کمک کنترل دسترسی سلسله‌مراتبی محافظت کرد، یا با اینکه با برچسب‌های حساسیت آن را پیاده‌سازی کرد. آنچه که روش را «اجباری» می‌سازد استفاده حتمی از «قاعده» یا «برچسب حساسیت» است.
معمولاً از دو روش برای اعمال کنترل دسترسی اجباری استفاده می‌شود:
سامانه‌های کمی MAC را پیاده‌سازی می‌کنند؛ و SELinux مثال‌هایی از سامانه‌هایی هستند که MAC را پیاده‌سازی کرده‌اند.
کنترل دسترسی مبتنی بر نقش (RBAC) یک سیاست دسترسی است که توسط سامانه تعیین می‌گردد، و نه توسط مالک. از RBAC در کاربردهای تجاری و نیز در سامانه‌های نظامی استفاده می‌شود، که در آن نیازمندی‌های امنیتی چند مرحله ای می‌تواند وجود داشته باشد. RBAC با DAC متفاوت است زیرا DAC به کاربران کنترل دسترسی به منابع‌اش را می‌دهد، درحالیکه در RBAC، دسترسی در سطح سامانه کنترل می‌گردد، یعنی خارج از کنترل کاربر است. اگرچه RBAC غیراختیاری است، در درجه اول، از نظر روشی که مجوزها رسیدگی می‌شوند، از MAC متمایز می‌شود. MAC مجوزهای خواندن و نوشتن را بر اساس مرحله صدور کاربر و دیگر برچسب‌ها کنترل می‌کند. RBAC مجموعه‌ای از مجوزهایی را که می‌تواند شامل عملیات پیچیده‌ای مثل تراکنش‌های تجارت الکترونیکی باشد، و همچنین می‌تواند به اندازه خواندن و نوشتن ساده باشد، کنترل می‌کند. یک نقش در RBAC را می‌توان به صورت مجموعه‌ای از مجوزها در نظر گرفت.
سه قاعده اصلی برای RBAC تعریف شده‌است:
محدودیت‌های اضافی نیز قابل اعمال است، همچنین نقش‌ها را می‌توان به صورت سلسله مراتبی ترکیب کرد، که در آن نقش‌های سطح بالاتر، شامل مجوزهایی است که به زیرنقش‌های سطح پایین‌تر تعلق دارند.
بیشتر فروشندگان IT این کنترل RBAC را در یک یا بیشتر از محصولاتشان ارائه کرده‌اند.
در (ABAC) دسترسی بر اساس حق فاعل مرتبط با یک کاربر بعد از احرازهویت اعطا نمی‌شود، بلکه بر اساس ویژگی‌های کاربر حق اعطا می‌شود. کاربر باید به اصطلاح ادعاها را دربارهٔ ویژگی‌هایش اثبات کند تا به موتور کنترل دسترسی داشته باشد. یک سیاست کنترل دسترسی مبتنی بر ویژگی، ادعاهایی را برای اعطای دسترسی به یک مفعول، باید برآورده‌سازی کند. برای مثال ادعا می‌تواند «مسن تر از ۱۸ سال» باشد. به هر کاربری که می‌تواند این ادعا را اثبات کند، دسترسی اعطا می‌شود. کاربران موقعی بینام هستند که احرازهویت و شناسایی حتماً مورد نیاز نیست. راه‌هایی برای اثبات ادعا به صورت بینام می‌تواند مورد نیاز باشد. این موضوع از طریق قابل دستیابی است. XACML (زبان نشان‌گذاری کنترل دسترسی گسترش‌پذیر) یک استاندارد برای کنترل دسترسی مبتنی بر ویژگی است. ورژن ۳ برای در ژانویه ۲۰۱۳ استانداردسازی شد.
به صورت سنتی دسترسی، هدف محدودسازی دسترسی را دارد، بنابراین بیشتر مدل‌های کنترل دسترسی از «اصل انکار پیش‌فرض» پیروی می‌کنند، که این یعنی اگر یک تقاضای دسترسی خاص به صورت صریح اجازه داده نشود، آن دسترسی رد می‌شود. این رفتار می‌تواند با عملیات عادی یک سامانه ناسازگار باشد. در وضعیت‌های خاص، انسان‌ها باید ریسکی را بپذیرند، که در آن ریسک، یک سیاست کنترل دسترسی نقض می‌شود، این موضوع در صورتی رخ می‌دهد که مزیت‌های بالقوه ای که می‌توان به آن رسید، از آن ریسک مهمتر است. این نیازمندی مخصوصا در دامنه مراقبت‌های سلامتی قابل مشاهده است، که در آن دسترسی‌های رد شده به رکوردهای بیمار می‌تواند منجر به مرگ بیمار شود. «شکستن شیشه» می‌خواهد این موضوع را کاهش دهد این کار از طریق ایجاد امکان رونویسی تصمیم کنترل دسترسی توسط کاربر قابل انجام است. «شکستن شیشه» را می‌توان به روش خاص کنترل دسترسی (مثلاً توسط RBAC) یا به صورت عمومی (یعنی مستقل از مدل کنترل دسترسی زیربنایی) پیاده‌سازی کرد.
ابتکار HBAC برای «کنترل دسترسی مبتنی بر میزبان» به کار می‌رود.