From what I understood about SBCs (by virtue of providing the networks, firewalls and routing for SBC deployments), an SBC does not (need to) actually route/forward IP packets between customer and SP network. 
There is the customer LAN side, with an interface and IP address (and if needed routing configuration) to match the customer's environment. It will only ever exchange data (mainly some SIP dialect and RTP streams) with customer's equipment (most probably the PBX).
There is the service provider side, with an interface and IP address (and if needed routing configuration) to match the SP's network. It will only ever exchange data (mainly SIP and RTP) with the SP's network.
The SBC itself is something like a dual homed proxy host: SIP and RTP flows are terminated on one and (re)initiated from the other interface (and vice-versa), so there is no need to actually route/forward packets between customer side and SP side - hence there is no need to NAT.
Some simple interface access lists on the SP Interface, permitting relevant traffic to/from the SP side interface might be enough to completely lock it down and have your network unexposed, all without the need for and the hassle of NAT.
Optionally, you may want to consider putting the SP side interface into its own "stub VRF" (VRF with only a single interface and it's own default route). However, that would require that the SBC related config items for the SP side are (or can be made) VRF-aware.
Setting up an SBC will add another "application layer hop" in the Voice streams between your PBX and the SIP peer systems at your Service provider, either between yor PBX and gateway or between gateway and SP. Make sure that your networking team is comfortable with understandig how the SBC works and the accepts responsibility to maintain an integral part of the VoIP solution
 the key clue to this assumption: I only ever needed to establish connectivity between PBX and the LAN/customer side of the SBC. Never did I have to add any routing configuration for the SP Network (or IP addresses/ranges of their SIP service) towards the LAN/customer side of the SBC. I did ask the SBC implementators multiple times if that wasn't needed - and they kept confirming that it wasn't.