Tried to connect my hashpack wallet with a hedera based NFT maeketplace and I have encountered this error.
"No available wallets - Ledger accounts are unable to be used with HashConnect. Please create a non-ledger account."
what exactly mean by a non ledger account
I am expecting to connect my hashpac wallet and perform various operations with theat nft marketplace
I found the basic diff between the ledger and non-ledger accounts now. Though the hashpack is a non-ledger account I could not able to figure out why it is not connecting and stating the same.
A Ledger account refers to an account on the Hedera network that is associated with a Ledger hardware wallet. Ledger is a popular hardware wallet that allows you to securely store your cryptocurrency assets offline.
A non-Ledger account, on the other hand, is an account on the Hedera network that is not associated with a Ledger hardware wallet. It is typically created using a software wallet, such as the Hashpac wallet, or through a software development kit (SDK).
When you create an account on the Hedera network using a Ledger hardware wallet, the private key associated with the account is stored securely on the device. This provides an additional layer of security, as the private key cannot be easily accessed by hackers or other malicious actors. However, using a Ledger hardware wallet to manage your account can sometimes be more cumbersome than using a software wallet, as it requires you to physically connect the device to your computer and enter a PIN code to access your funds.
In contrast, a non-Ledger account is typically easier to manage, as it can be accessed using a software wallet that is installed on your computer or mobile device. While the security of a software wallet may not be as robust as a hardware wallet like Ledger, it can still be secure when proper security measures are taken.
When connecting to the Hashpac wallet, you may need to create a non-Ledger account in order to interact with the wallet, as Ledger accounts are currently not supported
Related
The reader account can be used to share the data with users, where they can only run SELECT queries. How is it different than a user who is having a role with read-only access? What purpose does a reader account serve with a reader account?
Primarily, the Reader account purpose is to provide read-only data using shares to consumers, hence it is named reader account.
Reader account is not restricted by the conventional RBAC read-only privileges. You may create new users and grant any priviligies but the data that is being shared by the provider would be only read-only.
Reader account is one of the use cases for the Secure Data Sharing feature.
Details for all use cases: https://docs.snowflake.com/en/user-guide/data-share-providers.html
Reader accounts enable providers to share data with consumers who are not already Snowflake customers, without requiring the consumers to become Snowflake customers.
A reader account enables data consumers to access and query data shared by the provider of the account, with no setup or usage costs for the consumer, and no requirements for the consumer to sign a licensing agreement with Snowflake.
The reader account is created, owned, and managed by the provider account, which assumes all responsibility for credit charges incurred by users in the reader account. Similar to standard consumer accounts, the provider account uses shares to share databases with reader accounts; however, a reader account can only consume data from the provider account.
Details: https://docs.snowflake.com/en/user-guide/data-sharing-reader-create.html
Reader account is for users/consumers who are not on Snowflake. Reader account helps to keep the workload and management separate from your main account.
If you are a data provider, and you would like to share the data with one of your colleagues, for example, you would create a user for them in your main account. However, if you are a data provider, and would like to share the data with users outside your organization, that are not currently signed up for Snowflake, you will create a reader account for them, and share the data with that reader account.
In the latter case, the data consumers can then further manage the user management in the reader account, without you, as a data provider, having to do so.
Reader accounts are very handy in testing scenarios, where you would like to keep the testing completely separate from your actual (main) account, or, when you want to share data with consumers who do not want to sign up for Snowflake and handle billing.
I have a local Snowflake user account that is used for scheduled processes, like Tableau connections, etc. Regular Snowflake users have their own credentials that tie back to SSO/MFA systems (note: the SSO/MFA is NOT Snowflake's native SSO/MFA functionality.) I use the local user account to take advantage of scheduling and automation of SQL statements in external systems (e.g. Tableau), to avoid needing to MFA every time a connection is made or query is executed.
I would like to enhance the security measures around this local account, since it is not safeguarded by the SSO/MFA architecture that protects individual Snowflake users. Currently the only option that I have found is to create a Snowflake network policy that is assigned to the local user account, restricting to only the IP ranges that external systems call from.
What other options are there to secure these local user accounts?
The below article will help you with all the security measures available in Snowflake, along with best practices.
https://community.snowflake.com/s/article/Snowflake-Security-Overview-and-Best-Practices
Our organization is looking to bring on board the Alation product for data mining.
To do so, Alation requires a service account in Snowflake to touch every database, every schema in Snowflake.
Obviously this is very broad access and the org is concerned about security.
Has anyone else done this, and possibly quantify the risks involved?
We have to develop an application for companies that do machine maintenance. Each company has one or more eployees. Data has to be shared between employees and managers (Customers, orders, machine data etc).
The problem is that on site (where the work has to be done, and the software has to do its work) no internet connection is available.
How do we design the data storage architecture? How can data both be available offline, AND shared between different pc's if a network or internet connection is available?
We can use any Microsoft technology for this, except Metro.
Background
Though I've looked through some posts on stack-overflow that partially cover this point I'm yet to find one that provides a comprehensive question/answer.
As a developer of POS systems the PCI DSS has two components I'm interested in:
PA DSS (Payment Application) which regards the software I develop
PCI DSS (Merchants) which regards all my clients that use the software
The PA DSS seems to put the point most bluntly:
"9.1 The payment application must be developed such that the database server and web server are not required to be on the same server, nor is the database server required to be in the DMZ with the web server"
Testing Procedures:
9.1.a To verify that the payment application stores cardholder data in the internal network, and never in the DMZ, obtain evidence that the payment application does not require data storage in the DMZ, and will allow use of a DMZ to separate the Internet from systems storing cardholder data (e.g., payment application must not require that the database server and web server be on the same server, or in the DMZ with the web server).
9.1.b If customers could store cardholder data on a server connected to the Internet, examine PA-DSS Implementation Guide prepared by vendor to verify customers and resellers/integrators are told not to store cardholder data on Internet-accessible systems (e.g., web server and database server must not be on same server).
And from the merchant's PCI DSS:
1.3.5 Restrict outbound traffic from the cardholder data environment to the Internet such that outbound traffic can only access IP addresses within the DMZ.
Question
My question is quite simple - can the database and application server be logically different (on different virtualised OS) or must they be physically different (on different physical/dedicated servers)?
Also, I'm a bit concerned about having to place a database server with no connection to the Internet whatsoever. How am I supposed to administer this server remotely?
Or is it okay to access the database server via the application server - though surely that defeats the purpose?
No simple answer, sadly.
The SSC has released a new supplement on virtualisation which has some relevant information: https://www.pcisecuritystandards.org/documents/Virtualization_InfoSupp_v2.pdf
While mixing guest OSs of different functions on the same hypervisor is not prohibited, you will need to show that you've thought about the extra risk that this brings.
They will also have to be logically separated with network traffic from one VM to the other going through a firewall of some sort to protect the different OSs and applications. Being on the same physical host is not an excuse for skipping controls like firewalling so you may have to be creative about how you meet these requirements.