Azure provides an RPC security layer that enforces access control to the network. In order to provide authentication to your RPC interface you can use basic authentication, certificate based authentication or you can link to your identity provider.
After you are part of the network (rpc auth passe) you have Quorum state authorization layer (what is called the permissioning model) this authorization layer will enforce the separation between the private and public state (easier to understand by saying private vs public contract). However this layer does not enforce authorization beyond the separation between private and public state.
currently its up for the smart contract developer to provide a function based authorization model that suits their application (most commonly used one is "owner pattern"),
To put it in perspective; RPC Security -> Quorum state authorization layer -> custom built smart contract authorization layer.
Quorum Smart Contract based Permissioning framework provides a versatile way of managing a permissioned network, however it operates at the private/public state authorization layer not the smart contract function level.
Anyone on the internet who knows the RPC URL of any node in the
network and has a deployed contract's address & ABI, can create an
account on their laptop using web3.eth.accounts.create() and start
sending signed messages to read the state variables and execute any
functions of any smart contract deployed on the network.
If your RPC interface is insecure (no authentication required and binded to 0.0.0.0) then yes anyone will be able to interact with the network and interrogate the network, but that doesn't mean they will be able to interact with private state. that will happen only and only if the node exposed is part of the private circuit of an specific contract.
Anyone on the internet who knows the RPC URL of any node in the
network and has a deployed contract's address & ABI, can read state
variables and execute get functions of any smart contract deployed on
the network without the need for signing, by using the accounts stored
on the geth node itself.
No, the accounts has to be unlocked, and in order to unlock the accounts you need the password.
Is the authorization done by hardcoding the authorized accounts into
the contract and checking them within every function?
Yes if using "owner pattern"
happens when the account's private key is lost? Does the smart
contract become unusable?
if you lose private key of an account and you have a resource that depends on the signature from that account then its a game over.
I would recommend you to read the following:
http://docs.goquorum.com/en/latest/Security/Framework/Overview/
https://solidity.readthedocs.io/en/v0.4.24/common-patterns.html#restricting-access
https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/
