Particular embodiments generally relate to access control.
Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Access control requires a lot of administrative overhead. This is not only true for run time access of data manipulated and displayed by a software program, but also for the access control of the software development process. For example, software components (e.g., a collection of software artifacts written in a source code) have owners, development managers, and quality managers, who each control various aspects of a software component. Fixing a security issue, for example, may require a quality manager that reviews the mitigation of the security issue to ensure the component is sound.
Also, more objective and abstract access controls exist within development teams. For example, certain portions of the source code of a component may satisfy the functional security requirements of the component, and thus should only be written by the security expert for quality assurance. In another example, the architect may be tasked with explicitly dealing with parts of a component that interact with other components (e.g., external interface/signature design). To ensure that the component operates as defined by the architect in combination with other components, developers with a full understanding of a wider integration and architecture of a system may be limited to modifying these aspects of the component. Each team member that is involved in software development must be able to understand their access rights to source code. The responsibilities in the development may change and adapt frequently. Having a way for a developer to understand whether they are able to adapt a certain portion of source code enables the developers to understand their responsibilities for the component on a technical level. For example, an architect should understand the implications of his/her role within the source code.
Source code management systems may provide access control over who can access the source code of a component on the granularity of files used to store the source code (e.g., class files). For example, FIG. 1a shows an example of a software component in a file 100. In file 100, an access control scheme wants to make sure that no developer other than the architect can manipulate the interface of a class foo shown at 102. This may restrict access to public variable definitions. Also, access control may want to ensure that only database experts write code within the executeSQL code block shown at 104. However, because the component is in the same file 100, the different levels of access control that are desired cannot be set. In one example, file 100 may be split and a partial class definition where a single class can be split across multiple files may be used. The multiple files may then be individually controlled. However, splitting a class into multiple files may be inconvenient. Also, the access control is still on the file level.
Typically, to ensure the quality of the component is met, manual reviews of the component, such as the interfaces and the coding of methods, must be made to ensure correctness. This may lead to high overhead in the development lifecycle because potentially anyone could have changed/modified software code.
Also, the above access control over source code may also allow developers to modify parts of the source code in a malicious way. For example, developers may purposely modify parts of the source code to escalate their own privileges within a system, ensure authentication is dropped, or introduce a manual backdoor to the source code. Often, applications may run with different usernames and access rights on a database. This may allow a user to access the database through the application. For example, an application might have access at run time to all sales order records within a database as it logs into the database under a user “database_application_user”. A developer, however, may not have privileges to access this database under his/her own username. But, the developer may have access rights to the source code of the application that can execute and access the database. Thus, the developer can manipulate the source code to view the contents of the database when the developer compiles and executes the application.
An example of access to the database that may be written in the source code is shown in FIG. 1b. FIG. 1b shows an example of database code. In the executeSQL method, a database expert who has knowledge and access to resources manipulated by the software program may write code to manipulate the database as shown at 106. The statement at 106 executes the statement “bar” against the database. A developer who may not have access rights to the database may add a statement to this method that allows access to the database. For example, FIG. 1c shows an example of a statement that allows access to a database. At 108, a logical statement of “SELECT * from Table” is added to the method that allows access to the database content (SELECT * from Table). Without any form of access control, a developer may make this modification, compile the software program, and be able to access the database. The developer may then later remove these extra lines of code and any system, such as a version control system, will not notice that the developer added these lines if the lines were never checked in. The software program will just be registered as the executor of the SQL statement of the database of logged files.