Is it correct to implement this?

No. The approach is incorrect for handling collections because it makes the record manipulation procedure complex and poor in terms of performance.

You are defining a class that stores data and self-management at the same time. Pro case of 1000 records, for example, you would have to call insert 1000 times, being one for each object. The biggest problem is memory spending, replicating 1000 times objects with the same business logic.

Otherwise what would be a better approach, taking into account design patterns?

This is the classic case of implementing a repository, but there are some observations to make.

1. Separate the data class from the record manipulation class.

The CRUD class is correct from the point of view of a repository, except for the classe property, which is neither useful nor necessary for its implementation.

What is interesting to do is to use generic type to separate the class of data representation of the class that makes the operations in bank (common repository):

public abstract class CRUD<T>
    where T: IEntidade
{
    protected string tabela = null;
    protected object classe = null;

    public CRUD() {}

    public virtual void insert(T objeto) { //código }
    public virtual void select(int id) { //código }
    ...
}

2. Use generic classes to define your repository

PessoaCRUD does not have to be abstract :

public class PessoaCRUD<Pessoa> : CRUD<Pessoa>
{
   public PessoaCRUD()
   {
       tabela = "TBUsuarios";
   }

   //sobrescrita do metódo da classe pai
   public override void insert(Pessoa objeto) { //código }
}

Pessoa should only represent data:

public class Pessoa : IEntidade
{
    public int Id { get; set; }
    public string Nome { get; set; }
    public int Idade { get; set; }
}

3. Restrict your data classes by interfaces

Finally, set the IEntidade interface to define the format of the data representation classes:

public interface IEntidade 
{
    int Id { get; set; }
}

This implementation is coupling your business rules which I understand would be in the Person class with the access code to the database. It's interesting to separate things as you did, but the inheritance separates things from reading the code, but of course not, so it's best to use composition rather than inheritance. In this case you would still have the same classes, but the Person class would be passed as parameter to the PersonCRUD or the PersonCRUD could be injected into the Person class. I did not find links explaining the famous rule "Prefer composition instead of Inheritance" with C #, but that link aq is cool !

The person class represents a Person and a "crud" represents your people repository, they should not have a dependency based on inheritance because they represent distinct objects.

One represents one person from the real world and the other represents the place where you keep information. You are concentrating the repository details of people next to the person class. A better alternative would be to use abstract or even generics classes for the repositories and inherit a distinct repository for each object instance to be stored.

This will reduce the coupling and allow a lower maintenance level in the long run. Another problem is that since you're using the person class to inherit from the repository, if you're using layered architectures, you've just made life harder to make sure the higher layers do not access repositories directly.