Editing Access control (section)

== Computer security ==
{{Further|Computer access control}}

In [[computer security]], general access control includes [[authentication]], [[authorization]], and audit. A more narrow definition of access control would cover only access approval, whereby the system makes a decision to grant or reject an access request from an already authenticated subject, based on what the subject is authorized to access. Authentication and access control are often combined into a single operation, so that access is approved based on successful authentication, or based on an anonymous access token. Authentication methods and tokens include passwords, biometric analysis, physical keys, electronic keys and devices, hidden paths, social barriers, and monitoring by humans and automated systems.

In any access-control model, the entities that can perform actions on the system are called ''subjects'', and the entities representing resources to which access may need to be controlled are called ''objects'' (see also [[Access Control Matrix]]). Subjects and objects should both be considered as software entities, rather than as human users: any human users can only have an effect on the system via the software entities that they control.{{citation needed|date=February 2012}}

Although some systems equate subjects with ''user&nbsp;IDs'', so that all processes started by a user by default have the same authority, this level of control is not fine-grained enough to satisfy the [[principle of least privilege]], and arguably is responsible for the prevalence of [[malware]] in such systems (see [[computer insecurity]]).{{citation needed|date=February 2012}}

In some models, for example the [[object-capability model]], any software entity can potentially act as both subject and object.{{citation needed|date=February 2012}}

{{As of | 2014}}, access-control models tend to fall into one of two classes: those based on [[capability-based security|capabilities]] and those based on [[access control lists]] (ACLs).
* In a capability-based model, holding an unforgeable reference or ''capability'' to an object provides access to the object (roughly analogous to how possession of one's house key grants one access to one's house); access is conveyed to another party by transmitting such a capability over a secure channel
* In an ACL-based model, a subject's access to an object depends on whether its identity appears on a list associated with the object (roughly analogous to how a bouncer at a private party would check an ID to see if a name appears on the guest list); access is conveyed by editing the list. (Different ACL systems have a variety of different conventions regarding who or what is responsible for editing the list and how it is edited.){{citation needed|date=February 2012}}

Both capability-based and ACL-based models have mechanisms to allow access rights to be granted to all members of a ''group'' of subjects (often the group is itself modeled as a subject).{{citation needed|date=February 2012}}

Access control systems provide the essential services of ''authorization'', ''identification and authentication'' (''I&A''), ''access approval'', and ''accountability'' where:<ref>{{cite book |last1=Benantar |first1=M |title=Access Control Systems: Security, Identity Management and Trust Models |date=2010 |publisher=Springer |location=United Kingdom |isbn=9781441934734 |page=262}}</ref>

* authorization specifies what a subject can do
* identification and authentication ensure that only legitimate subjects can log on to a system
* access approval grants access during operations, by association of users with the resources that they are allowed to access, based on the authorization policy
* accountability identifies what a subject (or all subjects associated with a user) did

=== Access control models ===
Access to accounts can be enforced through many types of controls.<ref>{{cite web|url=http://www.evolllution.com/media_resources/cybersecurity-access-control/|title=Cybersecurity: Access Control|date=4 February 2014|access-date=11 September 2017}}</ref>
# [[Attribute-based access control|Attribute-based Access Control]] (ABAC) <br />An access control paradigm whereby access rights are granted to users through the use of policies which evaluate attributes (user attributes, resource attributes and environment conditions)<ref>{{Cite web |date=2014 |url=http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-162.pdf |title=SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations |publisher=NIST |access-date=8 December 2015 |url-status=dead |archive-url=https://web.archive.org/web/20160305222004/http://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf |archive-date=5 March 2016 }}</ref>
# [[Discretionary access control|Discretionary Access Control]] (DAC)<br />In DAC, the data owner determines who can access specific resources. For example, a system administrator may create a hierarchy of files to be accessed based on certain permissions.
# [[Graph-based access control|Graph-based Access Control]] (GBAC)<br />Compared to other approaches like RBAC or ABAC, the main difference is that in GBAC access rights are defined using an organizational query language instead of total enumeration.
# [[History-based access control|History-Based Access Control]] (HBAC)<br/>Access is granted or declined based on the real-time evaluation of a history of activities of the inquiring party, e.g. behavior, time between requests, content of requests.<ref>{{cite book |last=Schapranow |first=Matthieu-P. |date=2014 |title=Real-time Security Extensions for EPCglobal Networks |publisher=Springer |isbn=978-3-642-36342-9}}</ref> For example, the access to a certain service or data source can be granted or declined on the personal behavior, e.g. the request interval exceeds one query per second.
# [[History-of-presence based access control|History-of-Presence Based Access Control]] (HPBAC)<br/>Access control to resources is defined in terms of presence policies that need to be satisfied by presence records stored by the requestor. Policies are usually written in terms of frequency, spread and regularity. An example policy would be "The requestor has made k separate visitations, all within last week, and no two consecutive visitations are apart by more than T hours."<ref>{{cite book |last1=Pereira |first1=Henrique G. G. |last2=Fong |first2=Philip W. L. |title=Computer Security – ESORICS 2019 |chapter=SEPD: An Access Control Model for Resource Sharing in an IoT Environment |volume=11736 |date=2019 |pages=195–216 |doi=10.1007/978-3-030-29962-0_10 |publisher=Springer International Publishing |language=en|series=Lecture Notes in Computer Science |isbn=978-3-030-29961-3 |s2cid=202579712 }}</ref>
# [[Identity-based access control|Identity-Based Access Control]] (IBAC)<br />Using this network administrators can more effectively manage activity and access based on individual needs.<ref>{{citation|url=http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&co1=AND&d=PTXT&s1=8,984,620.PN.&OS=PN/8,984,620&RS=PN/8,984,620|title=Identity and policy-based network security and management system and method|author1=Sonwane, Abhilash Vijay|author2=Mahadevia, Jimit Hareshkumau|author3=Malek, Sarfaraz Mohammedhanif|author4=Pandya, Sumit|author5=Shah, Nishit Shantibhai|author6=Modhwadiya, Rajesh Hardasbhai|date=17 March 2015|publisher=USPTO Patent Full-Text and Image Database|access-date=19 June 2022|archive-date=6 November 2015|archive-url=https://archive.today/20151106174748/http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&co1=AND&d=PTXT&s1=8,984,620.PN.&OS=PN/8,984,620&RS=PN/8,984,620|url-status=bot: unknown}}</ref> 
# [[Lattice-based access control|Lattice-Based Access Control]] (LBAC)<br />A lattice is used to define the levels of security that an object may have and that a subject may have access to. The subject is only allowed to access an object if the security level of the subject is greater than or equal to that of the object.
# [[Mandatory access control|Mandatory Access Control]] (MAC)<br />In MAC, users do not have much freedom to determine who has access to their files. For example, security clearance of users and classification of data (as confidential, secret or top secret) are used as security labels to define the level of trust.
# [[Organisation-based access control|Organization-Based Access Control]] (OrBAC) <br /> OrBAC model allows the policy designer to define a security policy independently of the implementation<ref>{{cite web|url=http://orbac.org|title=OrBAC: Organization Based Access Control – The official OrBAC model website|website=orbac.org|access-date=11 September 2017|url-status=usurped|archive-url=https://web.archive.org/web/20170610205017/http://orbac.org/|archive-date=10 June 2017}}</ref>
# [[Relationship-based access control|Relationship-Based Access Control]] (ReBAC)<br />A subject's permission to access a resource is defined by the presence of relationships between those subjects and resources.
# [[Role-based access control|Role-Based Access Control]] (RBAC)<br />RBAC allows access based on the job title. RBAC largely eliminates discretion when providing access to objects. For example, a human resources specialist should not have permissions to create network accounts; this should be a role reserved for network administrators.
# [[Rule-based access control|Rule-Based Access Control]] (RAC)<br />RAC method, also referred to as Rule-Based Role-Based Access Control (RB-RBAC), is largely context based. Example of this would be allowing students to use labs only during a certain time of day; it is the combination of students' RBAC-based information system access control with the time-based lab access rules.
# [[Responsibility-based access control|Responsibility Based Access Control]] <br /> Information is accessed based on the responsibilities assigned to an actor or a business role<ref>{{cite web |last1=Feltus |first1=Christophe |last2=Petit |first2=Michaël |last3=Sloman |first3=Morris |title=Enhancement of Business IT Alignment by Including Responsibility Components in RBAC |url=http://ceur-ws.org/Vol-599/BUISTAL2010_Paper5.pdf |url-status=live |archive-url=https://web.archive.org/web/20160304063613/http://ceur-ws.org/Vol-599/BUISTAL2010_Paper5.pdf |archive-date=4 March 2016 |access-date=18 July 2014}}</ref>