Here at Ballard Chalmers, it is key that security and stability are not left until the last minute. Our policies in security, privacy and business continuity allow us to make the most of the services that Microsoft and especially Azure have to offer. And allow us to guide clients to the most appropriate levels for each system.
Our bespoke development processes help to determine the required levels to ensure a balance between the levels of security required and the cost of implementation of running. Thus allowing the client to define exactly what they require.
Security
Ballard Chalmers has a policy of “Security by Design”. We provide the following with respect to security when designing and developing applications for deployment in Azure:
- Developers follow OWASP best, and the OWASP top 10 in particular.
– This ensures the system is resilient against hacker attacks.
- For access between Services in Azure, Azure Active Directory will be used to secure each service using Service Principals (system user accounts) and CORS (Cross-Origin Resource Sharing).
– This ensures that the services are used only by the application and not by other applications or users.
Privacy
Ballard Chalmers has a general policy of “Privacy by Design” to protect private data stored in systems and to support GDPR.
We advise our clients as part of systems design that privacy should be taken into consideration. Though ultimately the client is responsible for defining how GDPR is applied to the data in their application and to ensure that this is reflected in the specification.
Some things to consider with respect to this are:
- Identifying private data (names, emails, IP addresses etc.) and ensuring it is encrypted at rest and processed according to GDPR rules.
- Controlling access to private data to just those users that need access.
- Ensuring that the owner of the private data has given consent to its use in the application.
- Providing features that identify and can report on data breaches.
- Creating a means to identify all data related to a particular person, to allow data requests by that user to be fulfilled.
- Producing a means to remove or anonymise personal data for a particular person at their request.
- Providing a means to archive or remove personal data after a designated period of non-use, such as 5 years.
Scalability
Azure has built–in scalability capabilities and any system we design and develop for Azure will be designed to take advantage of these where possible.
In particular:
- App Services for web applications and APIs will be configured to scale-out (i.e. add more servers) or scale-up (reconfigure to a more powerful server) automatically according to the load.
- Azure Functions are available in two modes, consumer plan and App Services plan. A choice will be made as part of the design on which to use:
– Consumer: Is inherently scalable at the API call level and is cheaper. But can cause delays the first time a function is called.
– App Services: Runs the functions in App Services which cost more, but can be more predictable. - SQL Azure is sized in a number of ways using DTUs (Database Throughput Units), or CPU Cores or as a dedicated Server Instance. DTUs will be used unless otherwise specifically designed.
– If usage is not even over a 24-hour period, then we can optionally auto resize the DTUs during the day. - Cosmos DB is sized in a number of ways using RTUs (Run Time Units) and by geographical replications and partitioning.
– If usage is not even over a 24-hour period, then we can optionally auto resize the RTUs during the day.
– Geographical replications and partitioning are only used if the application is specifically designed for it. - CDN (Content Delivery Network) can be used to automatically scale by distributing Web Applications and content geographically.
– This is only used when the system is specifically designed for it
Business Continuity and Disaster Recovery
Azure has built–in features to protect systems from failure. Systems we design and develop for Azure will take advantage of these where possible.
In particular:
- Where backups/replicas are included in the Azure service by default (e.g. Azure SQL, Azure Blob Storage, etc.), they will be included in the design.
– But no additional backups/replicas will be set up unless specifically detailed as part of the system design.
- In the event of Azure services (e.g. App Services, SQL Azure, Cosmos DB, Azure Storage) being unavailable, no business continuity will be set up unless requested.
– Where required, additional geographically redundant services can be included in the design but will be specific to that design and any requirements given. This usually involves replicating data to other data centres, together with a failover capability.
- The SLAs for uptime and connectivity will match those provided by Microsoft (https://azure.microsoft.com/en-gb/support/legal/sla/) for each service used in the design.
Summary
With Azure, Microsoft provides the tools to be secure and provide constant uptime. Our experts can help guide you to the right architecture for your solutions, and build these in from the very start of development.
