PostgresBC is a cloud-native Web3 data platform based on a Zero Trust data access model
2.1K
docker pull postgresbc/developer
PostgresBC has the Super User postgres set with the password postgres. It is important that you change this in each of your nodes. Also the root password is set to postgresbc again this should be changed.
To start your node type
docker run -dti -p5435:5435 postgresbc/developer
You can just run the above command and it will pull the latest verion automatically for you, if you do not already have it
This will run your node. You can then interact with it using PGAdmin or sql using localhost or IP 127.0.0.1
If you did not want to map a port then you would type
docker run -dit postgresbc/developer
You can then log in to the instancce with a bash shell and access PostgresBC from there using the psql tool.
The keys used by PostgresBC are derived. You can read an overview on derived key at NordVPN. The PostgresBC key derivation method takes an initial key which is unique to each instance and is created when you run the command
initialize '';
PostgresBC has the Super User postgres set with the password postgres. It is immportant that you change this in each of your nodes. Also the root password is set to postgresbc again this should be changed.
To start your node type
docker run -dti -p5435:5435 postgresbc/developer
You can just run the above command and it will pull the latest verion automatically for you, if you do not already have it
This will run your node. You can then interact with it using PGAdmin or sql using localhost or IP 127.0.0.1
If you did not want to map a port then you would type
docker run -it postgresbc/developer
You can then log in to the instancce with a bash shell and access PostgresBC from there using the psql tool.
The keys used by PostgresBC are derived. You can read an overview on derived key at NordVPN. The PostgresBC key derivation method takes an initial key which is unique to each instance and is created when you run the command
initialize '';
this command is automatically run when you first start up the container and will only be run once.
The key is generated using the openssl application locally on the instance passing random data to create an AES 256 key.
This key is then used as a salt within the derivation method, together with a password that is unique to that data. The method takes these two input and runs them through a method that alters the data. This is repeated up to 2,500 times before the key is passed back for use.
By using key derivation we are removing the inherent risks of a key store that requires keys to be passed to and from the instance so that it is able to encrypt and search the data.
Should you wish to have a separate copy of the aes-256 salt key, then please contact support directly and they will grant SSH access to the instance/s for a short while. Please note that we do not have access to these instances. When they were setup SSH was disabled and a unique password for root was created and passed to you. You will need this password to authenticate onto the instance with SSH.
To encrypt data in the store you must have created a field (table) or object (block) that has the word 'encrypt' appended to it. This tells postgresBC that the data supplied within this value is to be encrypted. On the initial creation of the table/block if PostgresBC will convert the object into two separate objects.
These 2 objects are not made public as are never directly accessed. If you have
Privileges on that table/block you will be able to search and see the decrypted value. However; Ig=f you only have
Privileges then you will be able to search on the data but you will never see its value.
E.g.:
You wish to have a count of all patients whose date of birth was in the year 1989. And the object 'birthdate' has been encrypted. Your query could be something like:
SELECT COUNT(*) FROM my_chain.my_block WHERE { birthdateencrypt LIKE '%1989%' };
Or
SELECT COUNT(*) FROM my_schema.my_table WHERE { birthdateencrypt LIKE '%1989%' };
If you did not have SELECT privilege then you would get back an error. If you have SELECT privilege you will get back the count. To see the actual data you will need SELECT and INSERT privileges and you could do a query like:
SELECT birthdateencrypt FROM my_chain.my_block;
This will show you the decrypted values. If you wish to test this. Login to PostgresBC as the postgres user and try the above query. You will get an error stating that the relation birthdateencrypt does not exists. Now try the following SQL again with the postgres user.
SELECT birthdateencrypt FROM my_chain.my_block;
Your result will be a lot of encrypted data and objects named birthdate_pgbc and birthdate_searchable. When accessing this objects with the correct privileges (I.e. NOT a Super User) then you will never have to see these two objects. By default a Super User does have access to all items within the database . But within PostgresBC they do not have access to the encrypted data EVER!
This section is yet to be completed
Web 3.0 or Web3 is the third generation of the World Wide Web (WWW), which involves direct immersion into the digital world. Web 3.0 encompasses individual control of personal data and the use of crypto currencies and blockchain. Currently a work in progress, it is a vision of a decentralized and open web with greater utility for its users. investopedia.com
Here at OmniIndex we believe that the owner of the data is the one who should have control of that data. For example. Your patient medical records. These are very private pieces of information that contain some incredibly personal information about you! Currently with most systems access to this information is approved by your medical practitioner, who passes a request to the system administrator who then grants permission to a person or organization to view and or amend the details. At no point in that transaction have you been explicitly asked to grant approval! We do not believe that this is the right way to handle data.
With PostgresBC you could and should be the data owner of your medical records. With a simple web interface that is fully protected you should be the one that grants authorization to an organization or user for a fixed period of time. In addition to this, the permissions you grant would be based on the need to know requirements of the person or organization being granted access. E.g.
You are going to have a CT scan Obviously the clinicians who are carrying out this scan need to update your records. But at no point do they need to see or be able to search across your records. If they need additional information they can ask you the medical reactionary who authorized the procedure. So for this organization you would provide
privileges on your records. This would allow them to add the CT scan data along with notes, but would not allow them to view any data.
Your insurance company requires access to your records for validating a claim This is a more complex use case, as the insurance company does need to see some personal information to make sure that the claim is correct. But; Do they need to see it all? Or could they verify the claim with search approval of your records? If the second then you could grant them
Privileges. This would allow them to search your records but never actually read the data. So verification could be carried out, by checking that you have a specific medical requirement, without actually being able to read any notes about that requirement.
You have a visit to a clinic with someone who is not your usual medical practitioner So here the medical clinician needs to read your records otherwise they will not be able to fully assess and diagnose any conditions. They also need to be able to update your records. However as your appointment is for a fixed time on a fixed data, it is possible to limit their access during this specified time period. For them you would provide
Privileges. Do not be put off by the update privilege here. PostgresBC is a Web 3 database. That means that certain records are immutable & cannot be updated. Only a new record inserted. The addition of the UPDATE privilege ensures that a mistake is much harder to make.
Smart contracts are digital contracts stored on a blockchain that are automatically executed when predetermined terms and conditions are met.
Smart contracts are typically used to automate the execution of an agreement so that all participants can be immediately certain of the outcome, without any intermediary’s involvement or time loss. They can also automate a workflow, triggering the next action when predetermined conditions are met. ibm.com
PostgresBC fully supports automatic creation of a smart contract. Each time you create a new user within the database it will tell you how a smart contract can be setup. To do All you need to do is to run the following command.
CREATE BLOCK IF NOT EXISTS <schema/chain>.<username>_contract (contractCount SERIAL, <Your Object List>);
This will take a template script and apply it within the database. Now every time you add a block then this script will run. If you wish to change this template it can be found within your instance at
/var/lib/postgresql/pgbc/sql/smart_contract.sql
PostgresBC natively supports the addition of multiple nodes. If you have purchased our standard edition it comes with 2 nodes. More can be added and the more the better, and each node can reside on different networks, in different data centers and on different infrastructure providers.
Each node is its own entity, with its' own encryption key and its own data store. But each is also linked to the others by an internal peer-to-peer network. Each node is updated in real time when one of the other nodes is changed. These changes could include
and more.
To add a node to the cluster you would run the following command
addnode (address, port, user, password, database);
NOTE Each node needs to be updated individually. For security reasons addnode is not clustered.
As has been stated the modification of data in a Web 3 data store is not permitted. However, in the real-world there are times when a record has to be deleted (GDPR/CCPA - Right to be forgotten). For this reason a database Super User is able to delete a record. This command though is never replicated across the nodes and as such needs to be carried out on each node individually.
Smart Contracts Smart contracts are digital contracts stored on a blockchain that are automatically executed when predetermined terms and conditions are met.
Smart contracts are typically used to automate the execution of an agreement so that all participants can be immediately certain of the outcome, without any intermediary’s involvement or time loss. They can also automate a workflow, triggering the next action when predetermined conditions are met. ibm.com
PostgresBC Support for Smart Contracts PostgresBC fully supports automatic creation of a smart contract. Each time you create a new user within the database it will tell you how a smart contract can be setup. To do All you need to do is to run the following command.
CREATE BLOCK IF NOT EXISTS <schema/chain>._contract (contractCount SERIAL, );
This will take a template script and apply it within the database. Now every time you add a block then this script will run. If you wish to change this template it can be found within your instance at
/var/lib/postgresql/pgbc/sql/smart_contract.sql
Nodes & Node Updating PostgresBC natively supports the addition of multiple nodes. If you have purchased our standard edition it comes with 2 nodes. More can be added and the more the better, and each node can reside on different networks, in different data centers and on different infrastructure providers.
Each node is its own entity, with its' own encryption key and its own data store. But each is also linked to the others by an internal peer-to-peer network. Each node is updated in real time when one of the other nodes is changed. These changes could include
Adding a Role Modifying a Role Adding a Chain Adding a Block Adding a Schema Adding a table
and more.
To add a node to the cluster you would run the following command
addnode (address, port, user, password, database);
NOTE Each node needs to be updated individually. For security reasons addnode is not clustered.
Need any help getting started? Our team, including technical support and community members, is ready to assist. Please post your questions here. ing random data to create an AES 256 key.
This key is then used as a salt within the derivation method, together with a password that is unique to that data. The method takes these two input and runs them through a method that alters the data. This is repeated up to 2,500 times before the key is passed back for use.
By using key derivation we are removing the inherent risks of a key store that requires keys to be passed to and from the instance so that it is able to encrypt and search the data.
Should you wish to have a separate copy of the aes-256 salt key, then please contact support directly and they will grant SSH access to the instance/s for a short while. Please note that we do not have access to these instances. When they were setup SSH was disabled and a unique password for root was created and passed to you. You will need this password to authenticate onto the instance with SSH.
To encrypt data in the store you must have created a field (table) or object (block) that has the word 'encrypt' appended to it. This tells postgresBC that the data supplied within this value is to be encrypted. On the initial creation of the table/block if PostgresBC will convert the object into two separate objects.
These 2 objects are not made public as are never directly accessed. If you have
Privileges on that table/block you will be able to search and see the decrypted value. However; Ig=f you only have
Privileges then you will be able to search on the data but you will never see its value.
E.g.:
You wish to have a count of all patients whose date of birth was in the year 1989. And the object 'birthdate' has been encrypted. Your query could be something like:
SELECT COUNT(*) FROM my_chain.my_block WHERE { birthdateencrypt LIKE '%1989%' };
Or
SELECT COUNT(*) FROM my_schema.my_table WHERE { birthdateencrypt LIKE '%1989%' };
If you did not have SELECT privilege then you would get back an error. If you have SELECT privilege you will get back the count. To see the actual data you will need SELECT and INSERT privileges and you could do a query like:
SELECT birthdateencrypt FROM my_chain.my_block;
This will show you the decrypted values. If you wish to test this. Login to PostgresBC as the postgres user and try the above query. You will get an error stating that the relation birthdateencrypt does not exists. Now try the following SQL again with the postgres user.
SELECT birthdateencrypt FROM my_chain.my_block;
Your result will be a lot of encrypted data and objects named birthdate_pgbc and birthdate_searchable. When accessing this objects with the correct privileges (I.e. NOT a Super User) then you will never have to see these two objects. By default a Super User does have access to all items within the database . But within PostgresBC they do not have access to the encrypted data EVER!
This section is yet to be completed
Web 3.0 or Web3 is the third generation of the World Wide Web (WWW), which involves direct immersion into the digital world. Web 3.0 encompasses individual control of personal data and the use of crypto currencies and blockchain. Currently a work in progress, it is a vision of a decentralized and open web with greater utility for its users. investopedia.com
Here at OmniIndex we believe that the owner of the data is the one who should have control of that data. For example. Your patient medical records. These are very private pieces of information that contain some incredibly personal information about you! Currently with most systems access to this information is approved by your medical practitioner, who passes a request to the system administrator who then grants permission to a person or organization to view and or amend the details. At no point in that transaction have you been explicitly asked to grant approval! We do not believe that this is the right way to handle data.
With PostgresBC you could and should be the data owner of your medical records. With a simple web interface that is fully protected you should be the one that grants authorization to an organization or user for a fixed period of time. In addition to this, the permissions you grant would be based on the need to know requirements of the person or organization being granted access. E.g.
You are going to have a CT scan Obviously the clinicians who are carrying out this scan need to update your records. But at no point do they need to see or be able to search across your records. If they need additional information they can ask you the medical reactionary who authorized the procedure. So for this organization you would provide
privileges on your records. This would allow them to add the CT scan data along with notes, but would not allow them to view any data.
Your insurance company requires access to your records for validating a claim This is a more complex use case, as the insurance company does need to see some personal information to make sure that the claim is correct. But; Do they need to see it all? Or could they verify the claim with search approval of your records? If the second then you could grant them
Privileges. This would allow them to search your records but never actually read the data. So verification could be carried out, by checking that you have a specific medical requirement, without actually being able to read any notes about that requirement.
You have a visit to a clinic with someone who is not your usual medical practitioner So here the medical clinician needs to read your records otherwise they will not be able to fully assess and diagnose any conditions. They also need to be able to update your records. However as your appointment is for a fixed time on a fixed data, it is possible to limit their access during this specified time period. For them you would provide
Privileges. Do not be put off by the update privilege here. PostgresBC is a Web 3 database. That means that certain records are immutable & cannot be updated. Only a new record inserted. The addition of the UPDATE privilege ensures that a mistake is much harder to make.
Smart contracts are digital contracts stored on a blockchain that are automatically executed when predetermined terms and conditions are met.
Smart contracts are typically used to automate the execution of an agreement so that all participants can be immediately certain of the outcome, without any intermediary’s involvement or time loss. They can also automate a workflow, triggering the next action when predetermined conditions are met. ibm.com
PostgresBC fully supports automatic creation of a smart contract. Each time you create a new user within the database it will tell you how a smart contract can be setup. To do All you need to do is to run the following command.
CREATE BLOCK IF NOT EXISTS <schema/chain>.<username>_contract (contractCount SERIAL, <Your Object List>);
This will take a template script and apply it within the database. Now every time you add a block then this script will run. If you wish to change this template it can be found within your instance at
/var/lib/postgresql/pgbc/sql/smart_contract.sql
PostgresBC natively supports the addition of multiple nodes. If you have purchased our standard edition it comes with 2 nodes. More can be added and the more the better, and each node can reside on different networks, in different data centers and on different infrastructure providers.
Each node is its own entity, with its' own encryption key and its own data store. But each is also linked to the others by an internal peer-to-peer network. Each node is updated in real time when one of the other nodes is changed. These changes could include
and more.
To add a node to the cluster you would run the following command
addnode (address, port, user, password, database);
NOTE Each node needs to be updated individually. For security reasons addnode is not clustered.
As has been stated the modification of data in a Web 3 data store is not permitted. However, in the real-world there are times when a record has to be deleted (GDPR/CCPA - Right to be forgotten). For this reason a database Super User is able to delete a record. This command though is never replicated across the nodes and as such needs to be carried out on each node individually.
Smart Contracts Smart contracts are digital contracts stored on a blockchain that are automatically executed when predetermined terms and conditions are met.
Smart contracts are typically used to automate the execution of an agreement so that all participants can be immediately certain of the outcome, without any intermediary’s involvement or time loss. They can also automate a workflow, triggering the next action when predetermined conditions are met. ibm.com
PostgresBC Support for Smart Contracts PostgresBC fully supports automatic creation of a smart contract. Each time you create a new user within the database it will tell you how a smart contract can be setup. To do All you need to do is to run the following command.
CREATE BLOCK IF NOT EXISTS <schema/chain>._contract (contractCount SERIAL, );
This will take a template script and apply it within the database. Now every time you add a block then this script will run. If you wish to change this template it can be found within your instance at
/var/lib/postgresql/pgbc/sql/smart_contract.sql
Nodes & Node Updating PostgresBC natively supports the addition of multiple nodes. If you have purchased our standard edition it comes with 2 nodes. More can be added and the more the better, and each node can reside on different networks, in different data centers and on different infrastructure providers.
Each node is its own entity, with its' own encryption key and its own data store. But each is also linked to the others by an internal peer-to-peer network. Each node is updated in real time when one of the other nodes is changed. These changes could include
Adding a Role Modifying a Role Adding a Chain Adding a Block Adding a Schema Adding a table
and more.
To add a node to the cluster you would run the following command
addnode (address, port, user, password, database);
NOTE Each node needs to be updated individually. For security reasons addnode is not clustered.
Need any help getting started? Our team, including technical support and community members, are ready to assist via our Discord server.
Content type
Image
Digest
sha256:02b62875f…
Size
662.9 MB
Last updated
over 1 year ago
docker pull postgresbc/developer