Azure Access Restriction - azure

We have multiple apps under one service plan and we want to restrict the access to development slots from outside the office, So my question is Can the access restriction rules be configured in one place and applied to all the development apps/slots?

Yes you can set it up. To add an access restriction rule to your app, use the menu to open Network>Access Restrictions and click on Configure Access Restrictions
From the Access Restrictions UI, you can review the list of access restriction rules defined for your app.
Here is the documentation

Related

Power Platform Canvas App only environment, app user permissions

I have been building canvas apps as part of solutions on non-default environments for a while.
Recently a customer required that the app be shared (to run, not edit) with an AAD security group's members.
The SG setup is as follows;
Image of SG setup
I imagined this to be simple and indeed I was able to 'Share' the canvas app with the SG.
However, users were unable to access the app even via a direct URL unless I gave them individual access.
I have spent many hours perusing the documentation and it seems that it is all aimed at 'Dynamics/CDS' environments.
The only way that i was able to share the app to them using the SG, was to create an environment DB add then to set the SG as the env SG.
Is that the correct approach?
It seems counter-intuitive because, according to MS, if an SG is not set to an environment, then all users can access the env?
First, make sure the group you are sharing with is really a security group or security-enabled M365 group.
You can't share an app with a distribution group in your organization or with a group outside your organization.
...
You can share an app with Microsoft 365 groups. However, the group must have security enabled
You can do that at Azure Portal:
Go to Azure AD Active Directory > Groups (direct URL)
Click [Columns] and add Security enabled column to the list
Find the group and make sure it is security-enabled
Also, make sure users have permissions to access and other resources
For a shared app to function as you expect, you must also manage permissions for the data source or sources on which the app is based, such as Microsoft Dataverse or Excel. You might also need to share other resources on which the app depends, such as flows, gateways, or connections.
Source: https://learn.microsoft.com/en-us/powerapps/maker/canvas-apps/share-app

Lock access to /admin url for live site (but not staging site) for specific roles/users

I have a kentico site built with portal engine and have staging and production/live environments. I'm wondering if it's possible to restrict/lock access to the admin area (/admin url) of the live site based on roles or privilege levels. Their access to staging site should remain the same. Thanks for your input!
There is no out of the box setting for this - you would need to use two sets of users and roles, separated in each environment and disable staging of users and roles. It is not possible to have the same user/role object on two environments with different behavior.

Share connection strings between web apps in Azure

In Azure there's the possibility of storing the Connection Strings in the "Application Settings" section of the online portal. This overrides the value in the web.config, which is very useful.
The issue is that I am having multiple web apps in Azure that all use the same connection string, so I would like to have one common entry in the portal where I can set this and all the apps should use it. Is this intentionally not possible because is bad practice, have I missed it or is it just not possible?
Application settings are always defined for the IIS instance running behind the scenes for your application. If you have multiple web apps, then they need to have the same settings duplicated.
However, what you are looking for is known as the External Configuration Store pattern.
External Configuration Store pattern
This pattern describes the situation where you got multiple applications where each need to access the same configuration. In this pattern, this is accomplished by saving the settings externally, in e.g. an Azure Storage blob.
From the above link, highlighted your described usecase:
When to use this pattern
This pattern is useful for:
Configuration settings that are shared between multiple applications and application instances, or where a standard configuration must be
enforced across multiple applications and application instances.
A standard configuration system that doesn't support all of the required configuration settings, such as storing images or complex
data types.
As a complementary store for some of the settings for applications, perhaps allowing applications to override some or all of the
centrally-stored settings.
As a way to simplify administration of multiple applications, and optionally for monitoring use of configuration settings by logging
some or all types of access to the configuration store.

rabbitmq-management plugin HTTP API - Security concerns

I want to enable RabbitMQ Management plugin on my production environment, but I'm not sure about the security concerns this might bring.
I already have a few applications connected to the RMQ, and hence can't change the credentials now (I'm using default).
Could anyone shed some light on this? I want to know what all things I might need to worry about and what I could do to minimise vulnerabilities.
Thanks!
Management Plugin use credentials, which is enough for most cases unless you want it to be accessible from outside. At this case iptables is your friend. In addition you can proxy HTTP api and management interface via nginx (or apache) and use additional security layer like basic auth.
If you are a bit paranoid (like me) you can combine all 3 methods to have more protection (and have non-trivial access to your management interface from non-usual locations like free wifi zone in airport when flow control get applied ont your server, but this is quite unusual situation).
UPD:
Note: if your application is badly-designed and mix routine job with management job under same account you may get into some troubles. I suggest you management plugin Permission section for further reading.
Usually, separate account for application and management job, as well as disabling default guest account (for outside only or in general) is the best choice from security point of view.
If you are forced to use default guest account you can disable management plugin for it and create separate account for administration only. In fact in recent RabbitMQ version it is disabled for accessing from outside.
To do this, firs create administration user (account with administrator tag), make sure it works and then update guest use by removing all tags it has (actually, removing administrator tag is the only one set by default for guest account).
Here is a pic of default guest account with note what to remove.

Securing SharePoint for Internal and External Users

We have both internal and external users on Windows SharePoint Services 3.0. We are using Windows Integrated authentication and have all users, both internal and external, in the same domain. We are allowing all users access to the application by adding the Domain Users group. The issue is that there are certain sites that need to be secure from the external users, but because they are in the same domain they have access. We have removed the Domain Users group from some sites and then explicitly assigned permissions to a dedicated group in Active Directory, but we have around 100 sites that we need to do this for and it would become an administrative nightmare to do this for all 100 sites.
I've done some searching and it looks like we might be able to accomplish this using zones, but when we tried last week we broke the entire application. Does anyone have any ideas?
The other option is to move the WSS server into a different domain and give the external users accounts in that domain so that we could keep them separate, but I wanted to see if there was a better way to do this.
Work on creating automation that creates and maintains Active Directory security groups that contain lists of internal or external users. Surely there is an attribute or two that distinguishes between these different types of users.
While you are at it, update your user provisioning process to make sure that when you create accounts, they get stuck in one group or another.
It would seem to be relatively simple to automate the process of changing your security using a powershell script?
An example of a script like that is here

Resources