I think in this case "best" is a relative term.
There are several ways to do it. long character separated string values, key value pairs, very wide tables with non-descript column names, possibly other ways I am not thinking of.
In the end, it depends on how you plan to use the data. Long character separated string values mean you need to have some way to parse that data when you get it before it is useful. Key value pairs mean you could end with a lot of rows to dig through to find what you are looking for.
Very wide non-descript tables I think is probably going to be the worst approach, but there are some cases where you may want that route. It is a bad approach as you are limiting the number of possible values that can be entered per application.
We have an application that is used as an "app launcher" where I work and we went with the key value pair approach. Then to determine if a user has access to run an application, we select applicationName from the table where username = abc. All applications that come back the user has permissions to run. There is a bit more logic in it than that as we are using the users AD credentials and we use AD groups as well as AD users, but that is the basic methodology for it. If we need a report based on it, we can filter by application or by user/group pretty easily. Our list of applications is pretty small and doesn't look like it will be growing too quickly anytime soon, so this approach works fine for us.
For application data (including app data inside the app launcher) we have one or more tables per application. Sometimes there is table overlap, but if the data is not related, we don't try to force it to be related. Using the above example with the key value pair, we have one table for application config information (where the app is located, the icon it should have, etc) and one table for app permissions. We tend to design the table around the purpose. So in your example, since it is used for application security, we would have that as an apppermission or appsecurity table and store things in key value pairs that would have a foreign key pointing to the application table. Where possible and where it makes sense, we normalize our data.