Overview
Today, LemonadeLXP uses Cloudflare’s web application firewall (WAF) and advanced DDoS attack protection services to ramp up security, and the Cloudflare network and managed DNS service to achieve better speed and performance.
We have three setup options, all of which stand on Cloudflare and AWS. It's important to note that none of these packages are "security upgrades" to one another; they are simply different ways of wiring the connection.
Three Setup Packages
Package One: Standard
You choose a subdomain (that you own) on which LemonadeLXP resides. For example, if you are https://firstbank.com, you could choose https://understand.firstbank.com.
If you also have Digital Academy, a second domain must be similarly chosen.
Once you have chosen your domains, we will give you NS addresses for each domain
Your tech team installs the NS records on your DNS
Cloudflare detects domain resolution (this can take a bit of time)
We take it from here!
Package Two: Custom SSL Package
Our standard package provides Cloudflare Secure SSL. If you would like to personalize your SSL certificate, we must complete all of the steps in package one, plus:
You must supply us with CSR details (we will help you with this)
We generate a CSR and provide it to you
You purchase the SSL cert from your approved vendor
You remit the SSL certificate to us, and we install it
This package incurs additional costs per domain:
A monthly fee applies, as this requires a more expensive Cloudflare plan.
SSL installation costs apply.
Package Three: CNAME package
If you have internal red tape that prohibits NS addresses, we can resort to a more complex CNAME setup. We will guide you through the process; this type of setup adds 2-3 days to the onboarding procedure.
This package supports Custom SSL.
This package incurs additional costs per domain:
A monthly fee applies, as this requires a more expensive Cloudflare plan.
If a custom SSL certificate is required, SSL installation costs apply.
Additional engineering costs are incurred while wiring your CNAME to our infrastructure.
Customers on a .bank domain name will require this setup type, to meet .bank domain requirements.
Notes
If you have the Digital Academy add-on for LLXP, the setup effort doubles because it requires its own (second) domain. You'll need to select a setup package for your Digital Academy domain.
A records cannot be used under any circumstance.
If your business has both external and internal DNS servers, you will need to create domain records in both places. More on this in the FAQ below.
⚠️ If you have modified, or plan to modify your DNS to add CAA records, you must heed the instructions in this article.
Bringing Your Own SSL Certificate
If you chose a package with Custom SSL, there are a few things to be aware of:
Imported certificates do not automatically renew. We will have to repeat the certificate-exchange exercise before your certificate expires.
Certificate expiry will have to be actively monitored and catalogued by your IT staff. When the certificate is near expiry, they need to send us a new certificate to replace the old.
A fee applies to each certificate manipulation, be it for installation, or renewal.
Frequently Asked Questions
Q. How long does setup take?
Packages one and two take approximately 2 business days to setup past the point of domain resolution. Our systems need for the domain to resolve before we can complete our setup.
For package three, please plan for about 4-5 days of setup time with your DNS team on standby to handle small DNS record creation requests.
Q. I have Internal and External DNS in my workplace. Can I limit the domain records (NS, or CNAME) to internal DNS only?
The hostnames used in the request are a core component of instance identification. Where an internal CNAME satisfies humans accessing the application servers, many microservice callbacks that depend on resolution would fail if the records weren't public.
For example, if Lambda attempts to leverage a reprocessing callback for the target instance, it will get DNS resolution failures when trying to invoke any instance-level APIs.
If the intention is to limit access to employees, we can use Cloudflare rules to restrict access to specific ingress points. It remains that the domain name must be visible to all parts of our infrastructure. Let us know if you’d like to explore this approach.
Q. I want Digital Academy, but for internal use only - is that possible?
Yes, under this circumstance, every learner that accesses Digital Academy will need to register into LemonadeLXP, and visit the academy internally through the LemonadeLXP header. In this type of setup, we do not need to complete the DNS component that yields the standard public view.
Q. Can I just use A records for my Internal or External DNS?
No. It’s vital to use NS delegation, or CNAME to wire your LemonadeLXP subdomain for technical reasons rooted in how DNS and how auto-provisioned architectures work. When you access a LemonadeLXP domain:
You type subdomain.yourdomain.com into your browser, which will query the authoritative DNS for yourdomain.com.
Authoritative DNS will return relegated NS records for Cloudflare.
Cloudflare is a reverse proxy that then queries the AWS ALB by DNS name (not by IP).
The AWS ALB will return its dynamic IP addresses (these change often) to Cloudflare.
Cloudflare reverse-proxies the connection and pipes the result(s) to the browser.
Behind the scenes, the ALB is doing the same thing; it will receive a hostname request, and will translate traffic to the right application fleet and its private subnets. IP addresses, in other words, change very often and can't be used as a beacon.
Because there are 2 layers of dynamic addressing across two private networks, address translation can't meet connection requirements. It’s necessary to follow the connection prescription described in our setup instructions. What's more, we prohibit traffic that is not signed from Cloudflare, as well, the (rotating) IP addresses of the fleet appliances are in a private network. Direct addressing (A records) can't solve this requirement.
Q. Do I need Cloudflare, can I use my own Firewall instead - we much prefer <insert other solution here>
Unfortunately that wouldn’t be an option, we need to govern our firewall rules as the application evolves. We also need to manage the firewall in response to threat events in realtime, and to be able to corroborate firewall data to SIEM data. Losing this corroboration would significantly compromise our security posture.
We’re open to adding IP-based rules to conform to your organization's needs if you'd like to limit IP access, but we must govern the security appliance that protects our infrastructure.
Q. Why should I get onto Cloudflare?
The short answer is: it's required.
The longer answer is that after an exhaustive and careful review of all available cloud-based security appliances, we chose Cloudflare to be an integral component of our network security stack. Beyond being what we believe is the best WAF on the market, it also provides a breadth of network optimization features that we've enmeshed with our service stack.
The combination of Cloudflare, AWS Shield, and AWS Guard Duty is integral to our security posture. Protecting your instance and data is of the utmost importance. Cloudflare's principal tasks are to:
Centralize the view of our first line of defense across all our instances.
Provide zero-day vulnerability detection.
Provide DDoS protection, Cloudflare was named a leader in the GigaOm Radar Report for DDoS Protection and has also received the highest amount of 'high' ratings with Gartner when compared to other 6 DDoS vendors.
Provide a beachhead for our WAF requirements (read more about what Cloudflare's WAF does here). "Fuzzing" and unauthorized scanning of our infrastructure has increased drastically over the years - and it's only getting worse. So far, Cloudflare has been the only solution to reliably detect and mitigate every DDoS and WAF surface attack we've witnessed.
Provides advanced bot management, bot-based attacks are increasing year over year, and Cloudflare reliably stops them in their tracks without impeding valid traffic.
PageShield is leveraged to prevent software supply chain attacks.
Cloudflare RateLimiting is also used to prevent attacks on authentication endpoints.
We also rely on Cloudflare to negotiate SSL for LemonadeLXP, in an E2E encryption configuration all the way to the application fleet using Authenticated Origin Pulls.
The Cloudflare Security Center is integral to our asset enumeration policies, plus, it performs regular scans on our behalf to ensure that network level configurations match required baselines.
Cloudflare Analytics are integral to our security posture, with SOPs wired to have our teams react to what Cloudflare detects with its advanced detection capabilities.
That's just the tip of the iceberg - it does so much more, such as: connection resumption, lossless image compression, automatic minification, 0-RTT, HTTP/2 prioritization...
Cloudflare has been a hard requirement since Q4/2021. We will be enforcing its use for clients onboarded before then as of Q2/2023, at which point direct access to the legacy ALB will stop working as the old ALB is decommissioned.