Data Access Governance

When designing your APIs, you can secure your data and ensure compliance with data governance policies in your organization by controlling how users access or view your data. Incorporate the following options as best practice guidelines in your team's API development:
lac42
When designing your APIs, you can secure your data and ensure compliance with data governance policies in your organization by controlling how users access or view your data. Incorporate the following options as best practice guidelines in your team's API development:
  • Resources that you define explicitly using API Creator.
     Select the applicable columns, specify aliases to provide meaningful column names, and join related data using resources. Resources provide a database abstraction layer for database access.
    For more information about the resources that you can define explicitly, see Customize your API.
  • Role-based endpoint access
    . For each role defined in your API, consider the appropriateness of the default access enabled. For example, if direct base entity (table or view) access is prohibited in your policies, you can disable all table-based REST endpoints.
    For more information about role-based endpoint access, see Authorization and Role-Based Endpoint Access.
  • Logic and row/column security
    . Control integrity (validation and computations), systems integration, and fine-grained row-level or column-level data access by defining your logic. 
    Layer7 Live API Creator
    automatically reuses the logic that you define across the verbs (insert, update, delete) and the resources that you create over the table. Logic provides separation of concerns (SoC) where logic and resource definition can proceed in parallel.
    For more information:
  • Functions.
     Wrap your calls to resources and their named filters, and choreograph calls on underlying data sources, using functions with parameters. Functions encapsulate the endpoint that an API user calls and the details on filters or named filters. For example, you can use a function that verifies arguments and invokes named filters on resources.
    For more information about functions, see Manage Functions.
  • Named filters.
     You can minimize risks to SQL injections by requiring that requests define only named filters.
    For more information about named filters, see Structured Filters.
For a list of all best practices, see Best Practices.