News for hackers. Stuff that matters.

A comment on Security 101 for SaaS startups. Parent comment

Re:Security 101 for SaaS startups by inopinatus on Tuesday March 07, 2017 @07:32PM (#13816714)
No. Absolutely not I'd say - because the purpose of an infrastructure domain isn't obscurity. That is simply a minor side-effect. The #1 reason is to assist in separation of concerns for the control plane, especially given the human factors in managing trust relationships between devices. The name should a) be instantly and recognisably distinct, b) easy and quick to type, and c) not creating risks of fuzzing a trust boundary due to misunderstood hierarchical naming.

Also, no-one should be using AD for SaaS infrastructure. It is a pretty good product for your enterprise internal services, but cannot handle the rather different needs of a SaaS system directory.

[ Parent | on HN ]
Re:Security 101 for SaaS startups by lykron on Wednesday March 08, 2017 @08:18AM (#13820010)
I'm not saying to use AD for a SaaS product, I'm saying the advice on having an obscure domain is a bad one. The SaaS product is saas.com, the company domain is company.com, and the IPA or AD Domain is domain.company.com. I don't see any good reason to have a 3rd domain floating around for directory services. If anything it is another thing to manage and keep track of.
[ Parent | on HN ]
Re:Security 101 for SaaS startups by programd on Tuesday March 07, 2017 @08:17PM (#13816953)
So what should be used for SaaS directory infrastructure?
[ Parent | on HN ]
Re:Security 101 for SaaS startups by inopinatus on Tuesday March 07, 2017 @09:53PM (#13817481)
That's a damn fine question. There's probably a book in it.

Briefly, though, keep it federated; layering integrity is super important for systematic consistency and quality, so wherever possible, entities should register using the tools provided by the PaaS/IaaS layers that the SaaS is inevitably running on. This includes any home-grown PaaS/IaaS, which are pretty common in SaaS at scale. I like to delegate a DNS subdomain to each subsystem, which is then served either natively from that subsystem (e.g. because its control plane used etcd) or using script-generated zones served by nsd. The only central aspect I want is the meta-directory that contains, ideally, nothing but delegations under the infrastructure domain name.

[ Parent | on HN ]