Secure File Uploads for Intercom

Secure File Uploads for Intercom(fibre.framer.website)

2 points by paulmbw 245 days ago | 2 comments

paulmbw 245 days ago |

TL;DR - We use Intercom for support and our customers need to upload sensitive docs (think proof of address, bank statements, etc.). Intercom’s native uploads aren’t a long-term fit for us (100MB/file limits, docs live on Intercom’s infra which screams data privacy issues for us) and we need files to land directly in our own storage. We may also want light scanning/summaries of docs so ops can triage faster.

SendSafely is a close solution but pricey -$11.50/user/mo, 10-user minimum). We’re also EU-based and want an EU-centric option.

So, we're building Fibre - Secure file uploads for Intercom and want to gauge interest.

We're thinking it will:

- run as an in-Messenger sheet (triggered from Intercom directly)

- ensure files bypass Intercom and go straight to a specified destination: S3, Google Drive, or Azure

- run webhooks on upload (e.g. notify via slack when a file is uploaded)

- encryption in transit and at rest so it's all secure

- optional lightweight doc scanning/summaries before an agent opens anything (as well as action items for each doc)

Short-lived agent download links (perhaps even password protected)

I'd love to get some initial feedback on this, specifically what you currently use for file uploads (do you use Intercom, SendSafely, or a custom solution). Feel free to comment below or send me a DM for more details

Thanks!

Bender 245 days ago | |

What I have done in the past was to create Chroot SFTP-Only accounts on servers for customers then restrict it to SSH keys and for paranoid customers also limit what CIDR blocks those keys are valid from. All of this is doable from within OpenSSH and storage would be limited to whatever size storage your company has on a server or set of servers or VM's. Each group or POD of customers could have their own active-standby servers only running OpenSSH and whatever monitoring tools your org uses. This could be on physical servers or VM's. Basic hardening is required such as restricting port-forwards, disabling multiplexing and so on. Cipher hardening would depend on if all your customers have modern versions of OpenSSH and avoid using proprietary SFTP clients, otherwise defaults or weaker than defaults may be required in some pods. Set up a active to standby sync of the customer chroot home directories and practice promoting the standby to active using an internal employee-only server.

All of this could be managed from either server automation or an in-house UI that gives customers ability to upload SSH keys and optionally define CIDR blocks and IP addresses the keys are valid from in a user interface.

Just me personally, I would keep it simple and avoid any "turn-key" solutions. Those are usually full of vulnerabilities. I would also avoid web services that could cancel your account locking you and your customers out of your and their data. Oh and a user agreement that sets a "best effort" service level agreement and start off telling the customers there is a 120 day file retention but then extend that as a free value add every quarter. From day one state that there are no backups and do not tell them about the standby servers.