There are several aspects to Ethereum and Hyperledger which make them quite different. Let me give a somewhat simplified answer to not get into too much details and a too long answer.
First of all, Ethereum is primarily a public blockchain that works in a certain intended way. Similarly, the Bitcoin blockchain works in a certain intended way. Hyperledger is not like that, rather it's an umbrella for distributed ledger technologies (in my terminology not the same as blockchain) which all aim to provide a very flexible architecture so that one can build all kinds of ledger-backed systems with pretty much any properties needed. One could compare this to an imaginary Bitcoin umbrella that provides technology to produce own altcoins with pluggable parts for e.g. consensus, blockchain storage, node composition etc. In short, all these aim to solve different problems and one should not think one will fit all.
Coming back to your questions.
1) Where is the contract stored?
Ethereum has contracts (called smart contracts) on the chain, i.e. code is compiled to byte code and the resulting bytes are sent within a transaction to be persisted onto the Ethereum blockchain. This is done once when you deploy the smart contract. After this one can interact with the smart contract with other transactions.
Hyperledger is in theory not defining this, it could be on a ledger or it might not. Take Fabric for instance, it deploys the code into a sandboxed Docker container which then can be interacted with using transactions.
2) How other participants such as customs and importer can access this contract?
Short answer is that they are given access via credentials.
This is in both Ethereum and Hyperledger open for you to decide yourself. We now assume the code in both cases has been deployed as code on the blockchain for Ethereum and as a Docker container in Fabric.
In Ethereum the code is, a bit simplified, publicly accessible/visible which means you need to employ some kind of check to only allow those who should be able to interact with the smart contract to do so. One way is to check the sender (of the transaction) and only allow certain ones. It's similar to traditional systems where one usually needs to authenticate/authorize to be allowed in and see/alter data.
In Hyperledger it would most likely be modelled in a similar manner and e.g. in Fabric there is also the Certificate Authority that hands out certificates that allow access to different parts of the system. E.g. transport, endorsement or transactions.
3) Can we activate participant level access to the contract on the blockchain?
Yes, so each participant in both systems has credentials and the designer of the smart contract can use this to control access.
Also, in Fabric there are channels that partition the ledger which is used for access control.
HTH.