4 ms·

Major problem with this is that your customers should ideally never expose their databases for public access.

nlh 3y ago
Second devil's advocate here: I know this isn't necessarily "good" in terms of security, but it's a very common pattern for higher-level tools these days to connect directly to databases. A LOT of marketing/analytics tools support this seemingly because users want this (see: Customer.IO, Looker, etc.) So again, I'm not saying you're wrong in that this might be a bad security practice, but OP is not alone in taking this approach and many SaaS vendors are seeing success and getting users because of it. So OP is going down a trodden path.
lmm 3y ago
Any serious database nowadays uses TLS and client certificates, at which point "exposing" the database is using the exact same crypto library that a VPN or jump host or what have you would use, and is just as secure.
xp84 3y ago
Devils advocate here: if you created a database user, which has access to a single View of with email, name, and whatever relevant subscription properties, how is that functionally different than what everyone does today which is to set up some Rube Goldberg contraption to pipe that audience information to mailchimp, sendgrid, or exacttarget? Personally, I find this really intriguing and think it would be much better for data security because it would be far less likely that they will have my customers’ email addresses lying around their database months or years after I cancelled the service.
- TZubiri 3y ago
  Right. It reminds me of SetVar and GetVar as a solution to exposing state
- failTide 3y ago
  you'd still be exposing the database system itself to the public regardless of the credentials you were using for the email service, as opposed to keeping it all within a VPC which seems to be what most guides recommend. I assume the difference would be that having your database exposed presents additional surface area for attacks. A rube-goldberg style setup probably presents its own risks, but personally I just use AWS SES for my transactional/marketing emails and it's a one-way pipe that doesn't present any significant risks as far as I can see.
  - 8organicbits 3y ago
    Using a public facing database, but using an IP address allow-list to restrict access is pretty secure. cc should publish the IP addresses they use.
    - kashnote 3y ago
      It’s listed on the Data page! No need to open the database up to the whole internet. Just whitelist one IP.
      - sakopov 3y ago
        Doesn't matter. The database still is on a public subnet on customer's network. All it takes is for someone to jack up some kind of white list or access rule and the entire database is exposed. It's an attack vector. You can't do this nearly as easily when the database is in a private subnet w/ no access to internet.
        deleted 3y ago
        [deleted]
        scrose 3y ago
        I mostly agree, but do want to emphasize that it really depends and there are multiple ways to secure this that range in complexity and maintenance overhead. The top thing that comes to mind is creating a separate ‘read replica’ DB that logically replicates target table(s) from the source DB, creates a materialized view with a subset of the replicated data in the replica db, and then exposes only the materialized view to a specific 3rd party user. That way you: 1) Run your primary db in a private subnet — addressing your concern with ip whitelisting 2) Run the replica in a public subnet with extremely limited access(ip-whitelisting and limited access controls to data). This is definitely a more complex setup to reason about and creates more moving parts that can fall out of sync, but it does greatly decrease the blast radius of a breach, and for some orgs, that may be a worthwhile trade-off. In my opinion, the OP would probably benefit from some basic security walkthroughs on these different implementations to help engineering teams get onboarded/make a better case for their solution if they hit friction with legal or security teams.

nlh 3y ago

Second devil's advocate here: I know this isn't necessarily "good" in terms of security, but it's a very common pattern for higher-level tools these days to connect directly to databases. A LOT of marketing/analytics tools support this seemingly because users want this (see: Customer.IO, Looker, etc.) So again, I'm not saying you're wrong in that this might be a bad security practice, but OP is not alone in taking this approach and many SaaS vendors are seeing success and getting users because of it. So OP is going down a trodden path.

lmm 3y ago

Any serious database nowadays uses TLS and client certificates, at which point "exposing" the database is using the exact same crypto library that a VPN or jump host or what have you would use, and is just as secure.

xp84 3y ago

Devils advocate here: if you created a database user, which has access to a single View of with email, name, and whatever relevant subscription properties, how is that functionally different than what everyone does today which is to set up some Rube Goldberg contraption to pipe that audience information to mailchimp, sendgrid, or exacttarget? Personally, I find this really intriguing and think it would be much better for data security because it would be far less likely that they will have my customers’ email addresses lying around their database months or years after I cancelled the service.

TZubiri 3y ago
Right. It reminds me of SetVar and GetVar as a solution to exposing state
failTide 3y ago
you'd still be exposing the database system itself to the public regardless of the credentials you were using for the email service, as opposed to keeping it all within a VPC which seems to be what most guides recommend. I assume the difference would be that having your database exposed presents additional surface area for attacks. A rube-goldberg style setup probably presents its own risks, but personally I just use AWS SES for my transactional/marketing emails and it's a one-way pipe that doesn't present any significant risks as far as I can see.
- 8organicbits 3y ago
  Using a public facing database, but using an IP address allow-list to restrict access is pretty secure. cc should publish the IP addresses they use.
  - kashnote 3y ago
    It’s listed on the Data page! No need to open the database up to the whole internet. Just whitelist one IP.
    - sakopov 3y ago
      Doesn't matter. The database still is on a public subnet on customer's network. All it takes is for someone to jack up some kind of white list or access rule and the entire database is exposed. It's an attack vector. You can't do this nearly as easily when the database is in a private subnet w/ no access to internet.
      - deleted 3y ago
        [deleted]
      - scrose 3y ago
        I mostly agree, but do want to emphasize that it really depends and there are multiple ways to secure this that range in complexity and maintenance overhead. The top thing that comes to mind is creating a separate ‘read replica’ DB that logically replicates target table(s) from the source DB, creates a materialized view with a subset of the replicated data in the replica db, and then exposes only the materialized view to a specific 3rd party user. That way you: 1) Run your primary db in a private subnet — addressing your concern with ip whitelisting 2) Run the replica in a public subnet with extremely limited access(ip-whitelisting and limited access controls to data). This is definitely a more complex setup to reason about and creates more moving parts that can fall out of sync, but it does greatly decrease the blast radius of a breach, and for some orgs, that may be a worthwhile trade-off. In my opinion, the OP would probably benefit from some basic security walkthroughs on these different implementations to help engineering teams get onboarded/make a better case for their solution if they hit friction with legal or security teams.