There is a requirement that we have a means for non-appian users to create new accounts in the application I am working on. Since Appian does not appear to have any built in means of allowing this, the current workaround is to make a web API that connects to an external site and kicks off a process model which can make new users. This kind of makes us nervous (particularly since there is no way to delete unnecessary users in Appian), so we added an admin approval step before the actual user creation stage, but we're still a little nervous about potential DDoS attacks and the like. Is there an in-Appian method to limit how often an API gets accessed? And if not, is there some other best practice to prevent attacks on Appian APIs?
Discussion posts and replies are publicly visible
In a typical enterprise scenario, you would put an API gateway in front of your Appian environment. This layer is meant to cover DDOS, throttling and defence in general.
Hi both,
Despite of having an API gateway, if your Appian install is public (internet) facing, how do you restrict from Appian that only the gateway will be accessing the ./webapi/... URL path?
Is there a way to restrict the incoming IPs, or similar to your APIs (from inside Appian, I know that we can configure our networks, Cloud, etc. to make those restrictions)
I'm more concerned in the mere exposure rather than the identification of the requester. E.g. prevent DDOS, as in general, APIs can be much abused than regular user navigation.
Regards,
here's a more direct and robust approach:
Implement Endpoint Authentication and Authorization in Appian: Within your Appian application, enforce authentication and authorization mechanisms directly on the API endpoints themselves. This can be achieved by implementing a custom authentication scheme or by leveraging Appian's built-in security features.
API Key Management: Generate unique API keys for each client or application that needs access to your API endpoints. Require clients to include these API keys in their requests for authentication purposes. Manage and validate these API keys within your Appian application to ensure that only authorized clients can access the API.
IP Whitelisting and Rate Limiting at the Gateway Level: Configure your API gateway to whitelist only specific IP addresses that are allowed to access the API endpoints. Additionally, implement rate limiting rules at the gateway level to restrict the number of requests per IP address within a certain timeframe. This helps in mitigating DDoS attacks and excessive usage.
Use Role-Based Access Control (RBAC): Utilize role-based access control mechanisms within your Appian application to define and enforce access policies for your API endpoints. Only users with the appropriate roles and permissions should be able to access sensitive or restricted endpoints.
Implement WAF and DDoS Protection Services: Deploy a Web Application Firewall (WAF) in front of your Appian application to inspect and filter incoming HTTP traffic. Additionally, consider utilizing DDoS protection services provided by cloud service providers or specialized security vendors to mitigate large-scale DDoS attacks.
Monitor and Audit API Access: Implement logging and monitoring mechanisms to track and audit API access in real-time. Monitor for any suspicious activity, such as unusual spikes in traffic or unauthorized access attempts, and take proactive measures to mitigate potential threats.
Regular Security Audits and Penetration Testing: Conduct regular security audits and penetration testing exercises to identify and address potential vulnerabilities in your API endpoints and overall application security posture. Address any security findings promptly to minimize the risk of exploitation.
By implementing these measures, you can significantly enhance the security of your API endpoints within Appian and mitigate the risks associated with unauthorized access, DDoS attacks, and abuse. Additionally, it's essential to stay informed about the latest security threats and best practices in API security to adapt and strengthen your defenses accordingly.
Thanks Manish for your quick response.
I really love extended responses like yours.
Going back to my question, I'm not concerned on user authentication (1,2 and 4) and I'm looking for a pro-active approach (where 6 and 7 are reactive).
I'm looking for configurations at Appian level, not in network devices (like 5).
I saw that, in cloud installations, we can request Appian support to configure those restrictions. Is this what you are referring on 3? For on-prem installs, could you please elaborate on option 3?
(I presume that, for cloud installs, what Appian does is configure their FW to prevent those unauthorised requests reaching your /webapi/xxx site)
Is this AI generated? If so, would you mind pointing this out?
Can you go into more detail?
What do you mean with "APIs can be much abused than regular user navigation"?
There's a bunch of ways to do this and it depends on a variety of factors (cloud vs on-prem etc.), whether you want to front the whole instance or just select paths (i.e. /admin, /webapis etc).
Here are a couple of links to get you started:
Hi Stefan,
For abused, I mean that the system can be queried massively and cause performance problems in our systems. It is not necessarily an "attack", it could be also an intended or unintended problem. E.g. a user is querying a service that list 5k records while he is only looking for 1... And the user is using the API because of his/her knowledge of the system and his laziness of login in and navigating to the proper functionality.
APIs in general are prepared to obtain data and can be queried continuously, while human interaction is usually more event based and once the event has been consumed, there is nothing else that can be done.
Hope this makes my concerns more clear.
Sure. When designing an API, you have to take the performance risks into account. Just limit the amount of returned data.
Keep in mind that Appian is NOT an integrations/API platform, but a process platform. Building an application in a way that it could be fully operated through API calls, does not feel like a good approach.
Hi Mathieu,
Thanks for your response. Again, these are very interesting recommendations for any Cloud approach, but all of them are based on the network topology surrounding the Appian installation, rather the Appian platform configuration itself.
I'm starting to think that Appian does not provide OOTB any way to control access (I'm not talking bout identification or authorisation, just pure access) to the APIs that are being exposed.
An example: if Appian is behind a normal load balancer, and this load balancer has no capabilities on controlling or restricting access depending on IPs, any user in the network segment with proper credentials will be able to access any available service (anything on ./webapi/...)
I'd like to configure in Appian that services ./webapi/... are only accessible/visible for a set of IPs, not needing to rely on the network topology and its configuration.
In the Cloud, this is trivial, as users are not in the cloud network segment and therefore, always travel through a FW. In on-prem installations, with complex networks, it is not always that easy to properly restrict users accessibility to network segments and those "smart" users tend like using postman, swagger, etc. to query APIs, rather than login into a user interface.
Usually, service and micro-service containers have the capability of doing such restrictions. I'm unable to find any in Appian. It looks like to prevent those undesired accesses we need to install Appian in an isolated network segment with a FW just in front of it.
Of course Stefan,
APIs must control the amount of data provided, either with paging or simply just limiting the amount of data provided forcing the requester for using a proper filtering.
But that does not prevent someone querying your system every second, right?
And the concern is that even Appian is not an API platform (if Appian sales hear you saying that Appian is not an integration platform, will get angry at you :) ). Even Appian is not an API platform, as it publishes services, it is exposed to the same risks and problems that an API platform.
And that's my point. We're in the middle. In my honest opinion, since the moment we publish services, we're exposed to all those problems and it seems that Appian is not able to prevent them by itself, for the documentation that I've found and the responses that you are so kindly providing.
Thanks again Stefan, i'll review the network topology and configs to ensure this is properly protected as it seems that there is nothing I can do from within Appian.