@DomC as some things were brought to my attention from elsewhere, (Not MongoDB, barely ever talk to anyone from it these days) I just want to be clear I am not employed by MongoDB, nor sponsored by it. Separation from MongoDB was back in end of Nov due to fictitious drama from someone external to MBD that I won’t get into here.
But in large I am very objective when it comes to MongoDB or any company for that matter, I just want to make it clear I’m not white knighting, nor am I worried or afraid of producing criticism or opinions about products or services, or actual known public facts. (Much of the time I wait until someone else exposes a problem I found previously before talking about it.)
In relation to your GraphQL that I’d like to make clear, yes, there are a lot of functionalities that aren’t supported, despite Apollo GraphQL fully supporting it. Yes, I can see where you can feel it isn’t production ready, in some aspects I do agree with you and on other aspects I have to heavily disagree. Because you should not be focusing on just GraphQL to secure your environment, nor should you be making Atlas itself the core focus of securing your environment.
Security is a culture, not a product. You need to make sure that you firmly understand that, in which your database is only one layer of the onion whether the feature is organic to it or not, there is always other ways to implement what you need.
This is coming from someone who’s worked on NIPRNET and SIPRNET networks and applications, who’s also worked on and developed applications used I can’t even discuss or go into specifics of that are used in high security environments.
I’ve also worked on penetration testing tools, RATs, vulnerability assessment tools, even reverse engineering tools to identify and break down an application to its machine code functionalities from compilation for exploitation.
When I say this, I do mean it. You will never have a fully secured environment, and there will always be a security vulnerability that you need to make the conscious effort to either accept the liability or mitigate the threat.
You also need to make stronger efforts besides password/email auth to really evaluate whether an application or service does, or can meet your applications needs. Coming from someone who’s assessed many applications for various reasons, even when people were panicking Seagate Harddrives had spyware built into them, you’re talking to one of the men who evaluated whether or not the situation was hyperbole. I also know the security team from the Air Force that handled the Ukraine power plant hack, and later worked in the evaluation of vulnerabilities and root causes of what allowed it to be breached in the first place. That’s my name among several in the report to Congress in 2016, and the report given to the EU by the company I contracted with when I say this.
If you would like help in working out the needs requirements for your application, and mitigations that could potentially workout what services may help you out, just let me know as I don’t mind. But “Atlas with GraphQL makes Brute forcing easy.” isn’t entirely accurate as you’re focusing on a server authentication and login error count without a handler. Which if MongoDB did implement said kind of handler feature, you then need to work on, and ensure it’s in sync with your SSO/LDAP/ETC. systems. Have a way to handle or mitigate false positives, and so on. Which honestly, your SSO solution, not Atlas should be responsible for that, but that’s just MHO.
And I would have edited and added this to my other post, but for some reason the edit button disappeared early? I’m not exactly sure.
Just my $0.02