How can you balance security and accessibility when debugging cloud apps?

Orgs can strike an effective balance by implementing strategies such as secure authentication and authorization, logging, monitoring, data protection measures, debugging tools with security features, access reviews and revocation, and training and awareness.

Knowledge Sharing and Training: Facilitate the creation of a cybersecurity consciousness among developers Regular Security Audits: Frequently perform the security assessments and audit of the debugging environment to find issues Temporary Debugging Access: Temporarily train on simple tasks to get the agent moving around until debugging tools or environments are required. Data Anonymization: Personal information of individuals should be safeguarded while diagnosing cloud applications as part of processes that request or access existing data. Logging and Monitoring: The cloud-based application must have a robust system of measurement and observability that will record the important occasions such as errors and security issues.

One thing I've found helpful is to make authentication as dynamic as possible when accessing production environments. If you use SSH to access an environment, use SSH certificates rather than allowing engineers to add their static keys. Certificates can be short-lived and audited on creation. If your cloud provider supports it, use a auditable privilege escalation system like Azure PIM so there is a record of why an engineer is accessing a secure environment.

Balancing security and accessibility during cloud app debugging involves implementing secure debugging practices, such as encrypted communication channels and limited access permissions. Utilizing logging and monitoring tools ensures visibility without compromising security. Regular security audits and adherence to best practices maintain a robust security posture while enabling efficient debugging processes.

More options: Airbrake: A cloud-based error and bug reporting solution that mainly suits small and big-size businesses. ReSharper: A renowned productivity tool that makes Microsoft Visual Studio a much better IDE. Angular Augury: A Google Chrome Dev Tools extension for debugging Angular applications. IBM Rational Software: A suite of tools for developing, testing, and debugging applications. Chrome DevTools: A set of web developer tools built directly into the Google Chrome browser. Fiddler: A free web debugging proxy that logs all HTTP(S) traffic between your computer and the Internet. Rookout: A data collection and pipeline tool, that provides a quick, simple, and secure method of collecting and delivering data.

Like coaches have preached for a long time, practice like you play. Push developers and operations teams to use the observability stack to troubleshoot and debug lower environments. If the telemetry there is not good enough, improve your approach to observability rather than just falling back on direct environment access. Walk through critical code paths and look for places that insightful metrics or logs can be published. Exceptional situations in the code should provide signals.

Less access to servers as they move toward production. Yes maybe a few trusted devs can have access to the development box, but when it comes to anything that is either directly production or even preproduction, limiting access to it to only a dedicated devops engineer or someone who really knows their way around it can help keep it secure as well as bounce back as fast as possible when a bug is introduced or anything that might stop its service.

I think that when debugging cloud apps, specially when the issue is isolated to a production environment, it's important to control the people who will be given access to the environment as well as the duration of the control. Ideally in a case like this, the production environment should be boxed in a very secure space, to mitigate further leakage / impacts with customers and the business. Giving very limited and specific access, that are needed to troubleshoot is key, and the importance of identifying each user that can help contribute to troubleshoot and replicate the issue, and then test the fix on a non prod environment before deploying to prod.

People spin up logs all day long and never look at them. How about this: never make a log unless you need it. And look at the logs you make! There's so much "just in case" mentality. Logs cost a lot. Only log what really needs logging from a historical perspective.

The entire data model should have an easily understood classification applied to it. When you take backups for a service, know what data is in that backup and the level of sensitivity of the data. If debugging a production issue that requires a data snapshot pulled into a reproduction environment, scrub data if possible to avoid extracting PII or PCI data from the controlled production environment.