You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p><strong>Infer Relationships</strong>: Automatically deduce relationships between entities. For instance, the rule engine could grant a user access to a file if they already have permission for the containing folder.</p>
250
250
</li>
251
251
</ul>
252
+
<h2id="principle-of-least-privilege"><aclass="header" href="#principle-of-least-privilege">Principle of Least Privilege</a></h2>
253
+
<p>The <ahref="https://www.cyberark.com/what-is/least-privilege/">principle of least privilege access control</a> widely referred to as least privilege, and PoLP is the security concept in which user(s) (employee(s)) are granted the minimum level of access/permissions to the app, data, or system that is required to perform his/her job functions.</p>
254
+
<p>To ensure PoLP is effectively enforced, we've compiled a list of best practices:</p>
255
+
<ul>
256
+
<li>
257
+
<p><strong>Conduct a thorough privilege audit</strong>: As we know, visibility is critical in an access environment, so conducting regular or periodic access audits of all privileged accounts can help your team gain complete visibility. This audit includes reviewing privileged accounts and credentials held by employees, contractors, and third-party vendors, whether on-premises, accessible remotely, or in the cloud. However, your team must also focus on default and hard-coded credentials, which IT teams often overlook.</p>
258
+
</li>
259
+
<li>
260
+
<p><strong>Establish the least privilege as the default</strong>: Start by granting new accounts the minimum privileges required for their tasks and eliminate or reconfigure default permissions on new systems or applications. Further, use role-based access control to help your team determine the necessary privileges for a new account by providing general guidelines based on roles and responsibilities. Also, your team needs to update and adjust access level permissions when the user's role changes; this will help prevent privilege creep.</p>
261
+
</li>
262
+
<li>
263
+
<p><strong>Enforce separation of privileges</strong>: Your team can prevent over-provisioning by limiting administrator privileges. Firstly, segregate administrative accounts from standard accounts, even if they belong to the same user, and isolate privileged user sessions. Then, grant administrative privileges (such as read, write, and execute permissions) only to the extent necessary for the user to perform their specific administrative tasks. This will help your team prevent granting users unnecessary or excessive control over critical systems, which could lead to security vulnerabilities or misconfigurations.</p>
264
+
</li>
265
+
<li>
266
+
<p><strong>Provide just-in-time, limited access</strong>: To maintain least-privilege access without hindering employee workflows, combine role-based access control with time-limited privileges. Further, replace hard-coded credentials with dynamic secrets or use one-time-use/temporary credentials. This will help your team grant temporary elevated access permissions when users need it, for instance, to complete specific tasks or short-term projects.</p>
267
+
</li>
268
+
<li>
269
+
<p><strong>Keep track and evaluate privileged access</strong>: Continuously monitor authentications and authorizations across your API platform and ensure all the individual actions are traceable. Additionally, record all authentication and authorizaiton sessions comprehensively, and use automated tools to swiftly identify any unusual activity or potential issues. These best practices are designed to enhance the security of your privileged accounts, data, and assets while ensuring compliance adherence and improving operational security without disrupting user workflows.</p>
<p>OpenAPI uses the term security scheme for authentication and authorization schemes. OpenAPI 3.0 lets you describe APIs protected using the following <ahref="https://swagger.io/docs/specification/v3_0/authentication/">security schemes</a>. The fine-grained authorization is just another layer of security and it is natural to define the fine-grained authorization in the same specification. It is can be done with OpenAPI specification extensions.</p>
274
+
<p>Extensions (also referred to as specification extensions or vendor extensions) are custom properties that start with x-, such as x-logo. They can be used to describe extra functionality that is not covered by the standard OpenAPI Specification. Many API-related products that support OpenAPI make use of extensions to document their own attributes, such as Amazon API Gateway, ReDoc, APIMatic and others.</p>
275
+
<p>As OpenAPI specification openapi.yaml is loaded during the light-4j startup, the extensions will be available at runtime in cache for each endpoint just like the scopes definition. The API owner can define the following two extensions for each endpoint:</p>
276
+
<ul>
277
+
<li>
278
+
<p><strong>x-request-access</strong>: This section allows designer to specify one or more <strong>rules</strong> as well as one or more security <strong>attributes</strong> for the input of the rules. For example, roles, location etc. The rule result will decide if the user has access to the endpoint based on the security attributes from the JWT token in the request chain.</p>
279
+
</li>
280
+
<li>
281
+
<p><strong>x-response-filter</strong>: This section is similar to the above; however, it works on the response chain. The rule result will decide which row or column of the response JSON will return to the user based on the security profile from the JWT token.</p>
282
+
</li>
283
+
</ul>
284
+
<p>Example of OpenAPI specification with fine-grained authorization.</p>
0 commit comments