Security is a really pertinent topic. All too often in the development world, there's an attitude of figuring security retroactively.
Join the DZone community and get the full member experience.Join For Free
Container Monitoring and Management eBook: Read about the new realities of containerization.
For instance, if software developers aren’t enforcing a secure software development methodology, the code might delight users and deliver necessary functionality, but security can end up as an (inadequate and ineffective) afterthought.
Alternatively, if operations teams don’t explicitly consider security as part of a service transition event, a service may never make it out of pre-production into a production environment, because it runs into the “just wait while we jigger the security systems” roadblock.
And this roadblock can be permanent.
In scenarios in which the pre-production environment isn’t an exact clone of the production environment—in most organizations, in other words—it’s impossible to fully implement and test the requisite changes to firewalls, IDS systems, and the like.
Rather than bolting on security as an afterthought, or manually tweaking the 10,000-line rule set of a single-point-of-failure choke-point firewall to secure a new service, security should be embedded within the service or application from the start. It should be made a part of deployment planning and testing from day one.
As the adage has it: “Begin as you mean to go on.” Assume security needs to be inherent in every project, service, or offering, and architect your environment and processes accordingly. If developers create their services in the same security environment in which they will eventually run, they can robustly test function and performance in the presence of security. If deployment engineers and architects can develop the operating practices for a new application in the presence of the same kind of security it will have in production, they can be both more complete and more accurate. Likewise, if the pre-production environment mirrors production, they can develop and fully test security configurations before the service transitions to production.
So far so good, but it’s not enough to have good intentions and matching preproduction and production environments. To deliver solid security in the emerging world of private cloud, hybrid cloud, microservice architectures, and DevOps, a security solution needs to support orchestration and automation via automated infrastructure provisioning and management tools, providing a foundation for repeatable, debuggable processes for deployment, testing, and management.
Both building security in sync with building the application (or its run-book) and making security a full-fledged, cloud-like service require security solutions that are fully API-enabled—that is, that have API access to all functions. Both also require, ultimately, that the solution is built to be granular, dynamic, and elastic, like the rest of the resources in a cloud environment:
Granular, so the work and complexity of securing an application can be spread out, with distinct enforcement points securing different parts of the environment.
Dynamic and elastic, so it can scale up and down as any given solution it secures does, and can deal with service components being movable among environments.
In sum, to build security in from the start and handle it at scale takes automation. And the more you automate, the more you can focus on delivering stellar functionality to users rather than worrying about security—whether as a roadblock or a cumbersome, ineffective, performance-killing afterthought.
Published at DZone with permission of Tatiana Crawford , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.