Achieving security by design

As we have seen up to here in the book, the opportunities and techniques we have for developing software are incredible. If you add all the information you will read about in relation to cloud computing in the next chapters, you will see that the opportunities just increase, as does the complexity to maintain all of this computing environment.

As a software architect, you must understand that these opportunities come with many responsibilities. The world has changed a lot in the last years. The second decade of the 21^st century has required lots of technology. Apps, social media, Industry 4.0, Big Data, and artificial intelligence are no longer future objectives, but mainly current projects that you will lead and deal with in your routine.

Considering this scenario, security must have a different approach. The world has moved to regulate companies that manage personal data. For instance, GDPR – the General Data Protection Regulation – is not only mandatory for European territory, since it has changed the way software is developed not only in Europe but all over the globe. There are many initiatives comparable to GDPR that must be enlisted to our belt of techniques and regulations, considering the software you design will be impacted by them.

Security by design must be one of your areas of focus for designing new applications. This subject is huge, and it is not going to be completely covered in this book, but as a software architect, you have to understand the necessity of having a specialist in the information security area in your team to guarantee the policies and the practices needed to avoid cyber attacks and maintain confidentiality, privacy, integrity, authenticity, and availability of the services you architect.

When it comes to protecting your ASP.NET Core application, it is worth mentioning that the framework has many features to help us out with that. For instance, it includes authentication and authorization patterns. In the OWASP Cheat Sheet Series, you'll be able to read about many other .NET practices.

The Open Web Application Security Project® (OWASP) is a nonprofit foundation that works to improve the security of software. Check out its information at https://owasp.org/.

ASP.NET also provides features to help us out with GDPR. Basically, there are APIs and templates to guide you in the implementation of policy declaration and cookie usage consent.

List of practices for achieving a safe architecture

The following list of practices related to security certainly does not cover the entirety of the subject. However, these practices will certainly help you, as a software architect, to explore some solutions related to this topic.

Authentication

Define an authentication method for your web app. There are many authentication options available nowadays, from ASP.NET Core Identity to external provider authentication methods, such as Facebook or Google. As a software architect, you must consider who the target audience of the application is. It would also be worth considering using Azure Active Directory as a starting point if you choose to go down this route.

You may find it useful to design authentication associated with Azure AD, a component for managing the Active Directory of the company you are working for. This alternative is pretty good in some scenarios, especially for internal usage. Azure currently offers Active Directory for usage as B2B – Business to Business, or B2C – Business to Consumer.

Depending on the scenario of the solution you are building, you will need to implement MFA – Multi Factor Authentication. The idea of this pattern is to ask for at least two forms of proof of identity before allowing the solution usage. It is worth mentioning that Azure AD facilitates this for you.

Do not forget that you must determine an authentication method for the APIs you provide. JSON Web Token is a pretty good pattern, and its usage is totally cross-platform.

You must determine the authorization model you will use in your web app. There are four model options:

1. Simple, where you just use the [Authorize] attribute in the class or method;
2. Role-based, in which you may declare Roles for accessing the Controller you are developing;
3. Claims-based, where you can define values that must be received during the authentication to indicate that the user is authorized;
4. Policy-based, in which there is a policy established to define the access in that Controller.

You may also define a controller or method in a class as being fully accessible to any user, by defining the attribute [AllowAnonymous]. Be sure this kind of implementation will not cause any vulnerabilities in the system you are designing.

The model you decide to use will define exactly what each user will be able to do in the application.

Sensitive data

While designing, you, as a software architect, will have to decide which part of the data you store is sensitive, and it will need to be protected. By connecting to Azure, your web app will be able to store protected data in components such as Azure Storage and Azure Key Vault. Storage in Azure will be discussed in Chapter 9, How to Choose Your Data Storage in the Cloud.

It is worth mentioning that Azure Key Vault is used to protect secrets your app may have. Consider using this solution when you have this kind of requirement.

Web security

It is totally unacceptable to have a production solution deployed without the HTTPS protocol enabled. Azure Web Apps and ASP.NET Core solutions have various possibilities to not only use but enforce the usage of this security protocol.

Thera are many known attacks and malicious patterns, such as cross-site request forgery, Open Redirect, and cross-site scripting. ASP.NET Core guarantees and presents APIs to solve them. You need to detect the ones that are useful for your solution.

Good programming practices, such as avoiding SQL injections by using parameters in your queries, is another important goal to achieve.

You may find cloud architecture security patterns at https://docs.microsoft.com/en-us/azure/architecture/patterns/category/security.

To finish, it is worth mentioning that security needs to be treated using the onion approach, which means that there are many layers of security to be implemented. You must have a policy determined to guarantee a process to access the data, including physical access to people who use the system you are developing. In addition, you will also have to develop a disaster recovery solution in case the system is attacked. The disaster recovery solution will depend on your cloud solution. We will discuss this later in Chapter 4, Deciding the Best Cloud-Based Solution.