3 ms·

Is anyone else deeply concerned that 37signals puts actual production data into their non-production environments (which are inherently insecure given the natur

by alberth 13y ago

Is anyone else deeply concerned that 37signals puts actual production data into their non-production environments (which are inherently insecure given the nature of those environments and who needs access to them)?

AhtiK 13y ago
Hypothetically speaking if the load-balancer is directing the traffic depending on the cookies then the environments can be very well separated behind the balancer. My other thought on this was if they use any separate static web asset management or it's all one single environment-switching for ruby. These days one could easily work with the stable REST server and all the web assets are switched between staging/beta/etc envs.
- alberth 13y ago
  You're thinking about external threats, I'm talking about internal threats. See my response to gyepi below for more info
gyepi 13y ago
No. If your non-production environments are less secure than your production environment, then you're doing something wrong. In fact, non-production environments generally have a much smaller population of users and they are tend to be more security minded. Or should be.
- alberth 13y ago
  You're missing the point. In non-production environments a large user base (eg developers, etc) have direct access to the database as needed for development. In production environments, they do not. This is exactly why data masking technologies exist. To mask/transform production data in non-production to that non-production has meaningful data but not REAL data
  - rmaccloy 13y ago
    I'm certain all 37s employees have access to the production database anyway; they're still a fairly small company. The only real additional risk here is running non-production code against live data; e.g. the risk of a feature branch sending extra email to customers. Given the nature of their products this is probably manageable, assuming they don't run batch jobs (via eg. resque)
  - gyepi 13y ago
    Fair enough, but if they were large enough to require that sort of privilege separation, then the entire post would make a lot less sense. Furthermore, I think the target audience has the same demographics; relatively small companies where the development team is also the production team. Thanks for the reference to data masking; it should be more common.
themcgruff 13y ago
We treat all environments as production. However we add additional security to staging since it's the most experimental. (Additional security meaning it can only be accessed via VPN and after two factor authentication.) To be very clear: Beta, production, rollout and staging environments are secure. They run all the same front end security provisions, same data center, same patches, etc. The difference is they run differing versions of the code base based on development.

by alberth 13y ago

AhtiK 13y ago

Hypothetically speaking if the load-balancer is directing the traffic depending on the cookies then the environments can be very well separated behind the balancer. My other thought on this was if they use any separate static web asset management or it's all one single environment-switching for ruby. These days one could easily work with the stable REST server and all the web assets are switched between staging/beta/etc envs.

alberth 13y ago
You're thinking about external threats, I'm talking about internal threats. See my response to gyepi below for more info

gyepi 13y ago

No. If your non-production environments are less secure than your production environment, then you're doing something wrong. In fact, non-production environments generally have a much smaller population of users and they are tend to be more security minded. Or should be.

alberth 13y ago
You're missing the point. In non-production environments a large user base (eg developers, etc) have direct access to the database as needed for development. In production environments, they do not. This is exactly why data masking technologies exist. To mask/transform production data in non-production to that non-production has meaningful data but not REAL data
- rmaccloy 13y ago
  I'm certain all 37s employees have access to the production database anyway; they're still a fairly small company. The only real additional risk here is running non-production code against live data; e.g. the risk of a feature branch sending extra email to customers. Given the nature of their products this is probably manageable, assuming they don't run batch jobs (via eg. resque)
- gyepi 13y ago
  Fair enough, but if they were large enough to require that sort of privilege separation, then the entire post would make a lot less sense. Furthermore, I think the target audience has the same demographics; relatively small companies where the development team is also the production team. Thanks for the reference to data masking; it should be more common.

themcgruff 13y ago

We treat all environments as production. However we add additional security to staging since it's the most experimental. (Additional security meaning it can only be accessed via VPN and after two factor authentication.) To be very clear: Beta, production, rollout and staging environments are secure. They run all the same front end security provisions, same data center, same patches, etc. The difference is they run differing versions of the code base based on development.