6 ms·
Original Author here. If you have questions or comments I would love hearing them.
by itaifrenkel 10y ago
Original Author here. If you have questions or comments I would love hearing them.
- sneak 10y agoSome of it seems like overkill. Now that Google Cloud Shell is a thing, the correct answer for small teams of people who are not security engineers is usually just "chromebook".
- itaifrenkel 10y agoI'm not familiar with it. How many startups that you know actually use it? Was it released only recently? Also, do you know of startups that use chrome books or toshiba zero client? Also keep in mind that laptops are used by data scientists and management
- eranid 10y agoAs a founder of a company I would gladly buy chromebooks for all employees if it would solve my security problems. Sadly, I don't think today there's one solution that addresses everyone's needs, balancing dev requirements with security (and I don't think here will be one so soon): 1. We are a company that develops for iOS, so we have Apple computers and laptops... Nothing to be done about that. 2. We are on AWS, switching to Google Cloud is definitely not for everyone, definitely not just for this feature. 3. Even if we had not been developing for iOS, some developers really value working on a MacBook, and in a highly competitive recruiting market, that's a factor, and not an insignificant one.
- sneak 10y agoI run 100% in AWS too and still use the (free) Google Cloud Shell for doing dev and orchestration and running terraform and docker-machine and whatnot.
- itaifrenkel 10y agoDo you mean that you use it as bastion host?
- jankedeen 10y agoThe biggest challenges are always internal/privileged access and policy/privilege, DR(ecovery|esponse), and maintenance/configuration management. You've covered these well. Couple notes: * VPNs are not panacea. My own experience is that ssh and significant key management (no password or emergency password only) is a more scalable strategy than relying solely on VPNs for small business. The whole default port thing with ssh is a no-brainer (don't do it + restrictive configurations of ssh for port forwarding and tunneling) as are the standard approaches to dealing with abuse of any service (fail2ban, etc...) Add to this a design which sandboxes ssh access based on time/privilege and only allows escape|access to critical resources via another mechanism. * WAFs are great but are extremely high maintenance and can be a productivity and production malf and bottleneck waiting to happen. * DDOS mitigation: https://www.akamai.com/us/en/solutions/products/cloud-security/ddos-protection-service.jsp https://www.akamai.com/us/en/solutions/products/cloud-securi... or the like.
- itaifrenkel 10y agoSSH does not cover all use cases. One example if you have an internal web service, how would you restrict access only to employees (without having it open to the internet?). SSO is not enough since you want the ports closed to non employees. Another example is accessing a database that is not configured with SSL. You don't want your info travelling in plaintext on the internet.
- jlgaddis 10y agoI work remotely. SSH is exactly what I use to access our internal-only (web) services.
- itaifrenkel 10y agoDo you use ssh as a socks proxy?
- jlgaddis 10y agoYes. Typically: $ ssh -D 8888 <bastion host> I have a Firefox add-on that makes it very easy to switch the proxy settings on and off.