Serverless360 has a powerful operational governance and auditing capability to maintain the logs of the user activities in the system. This feature helps the administrators to find out "Who did what" in the Azure integration scenario over a period of time. Consider a few example scenarios when the support user:
- Accidentally delete a Logic App
- Changes the properties of a Queue
- Repair and rebsubmit a message with incorrect details
In these situations, if the user action is recorded and logged as an event, it will help the administrator to identify the root cause of the issue. Right now, in Azure Portal, none of the activities are audited. This leaves organizations to run their support purely based on trust, which may not be ideal in some mission-critical situations like Healthcare, Financial services etc.
What Operations can be audited in Serverless360
Serverless360 has the capability to audit the following areas:
- CRUD Operations for Azure Service Bus Queues, Topics, Topic Subscription, Relays and Event Hubs
- RUD Operations for Azure Logic Apps and Azure Functions
- When you Resubmit, Repair and Resubmit, or Delete a Message from Azure Service Bus Queues or Topic Subscriptions
- Send messages to Azure Service Bus Queues or Topic Subscriptions
- Purge messages in Azure Service Bus Queues or Topic Subscriptions
- Send events to Event Hubs
- Scheduled send message and dead letter Activities
- Scheduled Events Activities
- Alert history
Giving Read-Only access to users in Serverless360
Enterprises face the challenge to provide access to their Azure Integrations to support users in different parts of the globe. Today, it is difficult for the administrators to keep track of the user activities and to restrict the shared access policy of the Azure entities for certain users through the Azure portal. Once the users have access to the Azure portal, they can pretty much do anything on the integration environment such as deleted/editing properties of a mission critical Azure entity which could lead to serious consequences for the organization.
Let's consider a scenario, ACME Corp has a built a complex integration scenario using distributed Azure services and they want their support enginners (first level people) across the world to have access to that Azure integration environment. In this case, the business requirement is to allow read-only access to that integration environment to the Level 1 support engineer. This means Scott (level 1 support engineer) will only be able to view the information in the environment and will not have the permission to make any changes to the configurations.
To achieve this, account owner/super user can create a normal user account for Scott in Serverless360.
Restricting Users to only selected Azure Services/Composite Applications
A typical Azure integration environment can have many Azure Services belonging to different business units or departments within the organization. With the Azure portal, it is not possible to segregate the integration scenarios for a specific set of users — say, "user 1 should only be able to access Azure Service Bus Queues and Topics, and user 2 should be able to access Azure Event Hubs and so on". With the Azure portal if an user by mistake, changes any configurations then that could lead to catastrophes in the business operations. Let's say, Bob, is the support person in ACME Corp who is responsible to manage and monitor only the Azure Service Bus Queues and Topics associated with a composite application. He must be able to access only that composite appliction and it is the responsibility of the account owner/super user to set up the access rights for Bob.